We have an existing application that is written in c++ and a relational database. The application needs to be rewritten in c#, the business want some kind of tracking what has changed when by whom. CQS seems good to work for read/write, but the event sourcing seems almost impossible, because the existing app will still need to be used together with the new app. The existing c++ application uses components (data-views) that writes directly in database. To evolve, we would have to change all those editable tables in the c++ app to call a service to our new app with commands, which is very costly.
We need an architecture where we can evolve from the old the the new without breaking the old c++ application, and they need to work together.
An idea we have is just preparing everything for event sourcing but not using it. Then creating some tracking tables where both apps writes to. Once a block is ready, we activate that part in the new app and deactivate it in the old c++ app.
But practically then, when is the best moment to store in the existing database during the transfer? In the CommandHandler? In the EventHandler? An event UserAdded may logically only be send when the user is really added. We think making temperory commandhandlers would be the best choice.
Or any other ideas?
