From monoliths to micro services using DDD and Mikado

A technical paper by Remus Pereni, Software Architect at Yonder

For those of you that appreciate more technical content and are interested in software architecture, here a short excerpt from the article. You can find the article on the download section or via the link at the end of this post.

There are many times when starting a new project as a monolith makes sense, especially in very lean projects where the requirements and the product are not entirely clear from the beginning. In such a project, the domain and domain models shift and change a lot as the application pivots, and the requirements evolve. As the project and product mature, hopefully, its domain takes shape and settles becoming more stable. By now, some parts of the domain will be more active than others.

This is the stage where micro services bring advantages, allowing the development teams to focus on smaller areas that are more manageable, easier to handle, test, and deploy. But that aspect also adds a bit of overhead as all these different domains require focus to integrate and automate. At the beginning of a project, almost all areas of the application evolve requiring continuous integrations and deployments. At that moment there is no real benefit in splitting them. Considering that the requirements might be too fragile and because of that the domain model of the application will be quite volatile, micro services add to the overhead as some may disappear or shift considerably.

Click here to go to the download area for the article.