Migrating from a monolith SQL based architecture to cqrs

[OrH]

Are there any recommendations for migrating from a working monolith SQL based architecture to a micro services architecture (cqrs and event source) using mongodb based on your libraries? (Which are awesome and very helpful!)

[adrai]

never migrated in my projects... huh! but I think there are a lot of consultants out there... 😜

[nanov]

There are a lot of considerations to take into account as it is really a redesign and just a simple migration.

Just a few points without knowing the particular case :

Do not try to fit every part of of your system in cqrs/es, it is perfectly fine to have crud (micro)services combined with es ones. Parts like user management for example are better fit for crud.

With that being set, with the parts that you do want to implement in a cqrs/es manner you have to be thinking task based and not data based. Talk to your domain experts to get an idea of real-world operations and tasks, this will help you design your domain.

Pay special attention to the message bus and the overall comminication layer between the services. Think about scenarios when one of them is down, error handling, persistence, concurrency and so on. A lot of those problems can be solved on the message bus level.

If you have any specific questions or examples it would be more easy to aid you.

Good luck!

[OrH]

@adrai haha got it =]

@nanov Thanks for the great response! But I already built the new system in cqrs/es and everything is almost ready and works great =]. My question was aimed more for the data migration (I wasn't clear about that). All my data needs to be migrated (relational sql to event source in mongo) and of course all "history changes" and current timestamps (createdAt, updatedAt, etc.) needs to be the same..

I was wondering if it's best to create "special" commands (maybe with a custom command handler) for the migrations which will allow me to do more stuff or maybe just create the data in mongodb directly without even going through the commands process.

[nanov]

Thanks an interesting ( and tricky ) issue.

I do not know your structure exactly, what do you mean by "history changes"? Have you maintained some kind of audit log?

Just out of the head I would create a migrate command ( this means you would have create and migrate command on each aggregate to be migrated ) and pass the wanted values trough this command ( including the original timestamps ), then you would have an event "migrated" ( which is supposed to be the first event in this aggregate, ie. aggregate starts life with create or migrate ) and then the rest is up to state managing / denormalization.

Simple example :

create -> created ( someData ) -> denormalizing ( someData, createdAt, updatedAt from commitstamp in the event for example ).

migrate -> migrated ( someData, updatedAt, createdAt ) -> denormalizing ( someData, createdAt, updatedAt from event, migratedAt from commitTimestamp ).

The same strategy could be used in the aggregate state in case needed.

[OrH]

Thanks again @nanov , that's what I also thought doing. Currently a migrate command seems the best idea. Hope it will go smoothly! 😄