![]() In a bounded context, you will have models that only make sense in that respective context, like the concept of "lead" (potential sales contact) will only make sense in the marketing context. Bounded contextsĪ bounded context has, as its name suggests, a boundary: each model has a clear and unequivocal meaning. Yet, this is precisely the concept of bounded context which is a central pattern in Domain Driven Design. The resulting models will be decoupled and will be made smaller, making them easier to maintain. Therefore, one way to split the monolith into autonomous services would be to partition these services per the business context, as many times these can be self-contained and will have the fewest dependencies.įigure 2 Each business context has its own, specific model of the product ![]() For somebody in sales, the value of the product has to do with the category, characteristics, image, while the colleague in procurement defines the product by delivery times, the number of products in batch, price per supplier, etc.Įach such different concept within the business context has its own meaning, even though it refers to the same physical product. The best approach to decoupling would be a single model for each business context containing a unique representation of the product that only satisfies the needs of its particular context. ![]() If we want to transform any context (completely or partly) into a micro service, this will have an impact on the other business contexts because of the shared model. Many times, a supermodel is constructed trying to contain all the aspects of the physical product: from stock which is a concern of the inventory context to pricing which is the responsibility of the sales context, to purchase orders which belongs to the procurement department, etc.įigure 1 Product is a giant concept being used in multiple business contextsĪs a result of these, we end up with a supermodel that is shared by many contexts. 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 Comments
Leave a Reply. |