Classic examples are the concept of patient or product. Good modeling practices exist to minimize coupling between modules or packages, yet the constraints of a monolith are not as drastic as those required in a micro-service.įor example, a common problem occurs when a physical entity in the domain is modeled as a single concept in the application and is used in different business contexts. Partitioning the systemĪ micro-service requires a clean model with little or no dependencies on other services, whereas the models in a monolith are already established. From this perspective, micro-services are just a different implementation of the core concepts of SOA, one that successfully addresses some of the pitfalls of the over-regulated and over-engineered ESB, WS-centered world. Although this already existed before micro services, DDD appeared in the context of service-oriented architectures (SOA) where the clean partitioning of services is a major factor. Some of the concepts and patterns introduced by Domain Driven Design (DDD) can be very helpful to answer these questions.Įric Evans presented the notion of Domain Driven Design (DDD), for the first time, in his book (under the same name) where he introduced patterns and principles to address the complexity in the development of business applications. However, once the application settles, how do you move it from a monolith to a micro-service based architecture? How do you partition the application? How do you ensure that those partitions are clean and not end up in a dependency nightmare? Where do you start to carve out functionality and how do you ensure that, at each step, you still have a product that you can ship and that your users can use? 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. At that moment, there is no real benefit in splitting them. At the beginning of a project, almost all areas of the application evolve requiring continuous integrations and deployments.
But that aspect also adds a bit of overhead as all these different domains require focus to integrate and automate. 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.
By now, some parts of the domain will be more active than others. As the project and product mature, hopefully, their domain takes shape and settles, becoming more stable. In such a project, the domain and domain models shift and change a lot as the application pivots, and the requirements evolve.
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.
0 kommentar(er)
