From monoliths to micro services using DDD and Mikado
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, their 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, as a result, the domain model of the application might be quite volatile, micro services add to the overhead, as some may disappear or shift considerably.
