Often, the start of a new project makes sense in the form of monoliths, particularly in lean projects where the requirements and the product itself are not very well established from the start. In such projects, application domain data models change and change a lot, once the application pivots and the requirements evolve. As the project and product mature, the data model and data field is becoming more and more stable. It’s time for some areas in the app to become more active than others.
This is the stage where microservices could bring benefits by allowing development teams to focus on smaller areas that become more manageable and more developed. Microservices also involve an extra effort from the need to integrate, configure and automate them. Because of this, at the beginning of a project, when almost all areas of a product are constantly evolving, and area sharing criteria in services can be changed frequently (some services often disappear completely or migrate to others), there are not enough benefits in their start up as microservices.
But once the application captures the outline, how do we make the transition from a monolith to a microservice application? How do we partition it? How do we ensure that all those partitions are well delimited and do not create dependencies that make development a nightmare? Where do we begin to migrate functionality and how do we ensure that we continue to have a stable application in every moment that we can exploit in production?
Some of the concepts and patterns introduced by Domain Driven Design (DDD) can be helpful in answering these questions. Eric Evans introduced the term Domain Driven Design (DDD) for the first time in his book (with the same name) where he presents patterns and principles that address the complexity of developing computer applications. Although these have occurred before the emergence of microservice concepts, DDD has emerged during the Service Oriented Architecture era, where well-defined service partitioning is equally important. From this perspective, microservices are a new implementation of the basic concepts present in SOA. True, it is an implementation that successfully analyzes many shortcomings in the Enterprise Service Bus-centered upregulated service area.
Systems partitioning: A potential problem is given by the fact that micro services are based on a clean model with little or no dependency on other services provided that an existing monolith has already established and implemented models. There are good modeling practices that minimize the coupling between modules and packages and provide the premises for a smooth transition. However, these constraints in a monolith are less drastic than microservice requirements.