Then we'll apply them to the Shipping bounded context in the Drone Delivery application. First, we'll review the tactical patterns. As a general principle, a microservice should be no smaller than an aggregate, and no larger than a bounded context. Applying these patterns will help us to identify natural boundaries for the services in our application (see the next article in this series). In a microservices architecture, we are particularly interested in the entity and aggregate patterns. The tactical patterns are applied within a single bounded context. Tactical DDD is when you define your domain models with more precision.
Looking at all the concepts he has described Pödl concludes by stating that microservices and DDD really fits well together but also notes that we must have a larger scope and look beyond bounded contexts.During the strategic phase of domain-driven design (DDD), you are mapping out the business domain and defining bounded contexts for your domain models. Without a clear vision and knowledge of the business capability the risk of not finding the optimal bounded contexts increases. Pödl emphasizes the importance of documenting the business capability and the details of the core domain. Starting with identifying and extracting the core domain it is then an iterative work of identifying a subdomain, extracting it from the core and finally with some clean-up internal refactoring. Moving from a legacy system to a microservices or self-contained system architecture the use of Distillation can help in extracting microservices out of an existing monolithic system. Responsibility layers is another structural pattern for creating an internal structure in a bounded context according to responsibilities but the concept can also be adapted structuring microservices in the same way. Plöd notes that this is also one the core ideas of microservices, they should be designed so that they can evolve. With an inflexible architecture or if a system becomes too complex it may be helpful to create a Large-scale structure across bounded contexts and letting this structure evolve towards a better understanding of the high-level concepts. It’s a group of domain objects handled together and with one entity the aggregate root through which all requests and responsible for the lifecycle of the aggregate. This is an interesting option especially when migrating to a microservices or a Self-Contained Systems (SCS) architecture since the ACL works as a protecting shield against the outside.Īmong the internal building blocks Plöd notes the special importance of the aggregate. Anticorruption layer ( ACL), where a client isolates its model from another model using a translation.Customer – Supplier, with one context acting as a customer asking for features from another context, the supplier.Plöd notes that this also increases the dependency.
Shared kernel meaning two contexts or models share a subset of a domain including code.Patterns for common types of relationships between two contexts include:
It can also be a great starting point for future transformations. For organisations with an existing landscape wanting to move to microservices Plöd believes that a context map may be especially useful. Using a customer as an example each bounded context has its own model and view of a customer and for Plöd this is a major enabler for independent microservices.Ī context map shows all bounded contexts and their relation to each other and also describes the contract between them. A bounded context contains models describing the domain and is also a boundary for the meaning of these models.
Microservices and Domain-Driven Design (DDD) are not only about Bounded contexts, although a fundamental tool for defining granularity of microservices there are other important concepts as well.
0 kommentar(er)
