Domain-Driven Design strategic patterns overview
:max_bytes(150000):strip_icc()/chess-strategy-tactics-4102130_final-5bfc6d06c9e77c005884899e.png)
Introduction : why you should apply DDD in your project ?
Domain-Driven Design is a software design approach that is about focusing on modeling software to match the domain according to input from one or multiple domain experts.
In this introduction we will see the major benefits of this approach and through this article we will do an overview of the strategic pattern of DDD which is about defining the Bounded contexts, the Ubiquitious language and Context maps.
DDD benefits:
Put together domain experts and developers as one cohesive team. build a software that is as close as possible to what the domain experts would create if they were able to code. The domain experts will teach the developers about the buisness but the opposite is also likely to happen. Centralizing knowledge. No translation between the domain experts and the developers thanks to the Ubiquitious language. A code base that actually represent the domain.
Domain, Subdomain, Supporting Subdomain, Generic Subdomain and Bounded Contexts
Domain:
A Domain, in the broad sense, is what an organization does and the world it does it in. Vaughn Vernon (famous DDD practioner and the author of Implementing Domain-Driven Design)
The domain itself is divided into three category of subdomain:
Core Domain:
It's the part of the software system that provides the most value to the organization like the e-commerce system of Amazon for example. That is also according to Vaughn Vernon where the best developers of the company should work.
Supporting Subdomain:
A supporting subdomain is a subdomain that provides services or capabilities that are important to the core domain, but are not themselves core to the business value proposition. A perfect exemple of Supporting Subdomain would a domain that has the responsability to handle authentification and authorization for the system.
Generic Subdomain:
Generic subdomains typically provide reusable functionality or services that are not tied to any particular business context, but which can be applied to a wide range of scenarios. Examples of generic subdomains might include things like emails notifcation, reporting and analytics.Because they are not specific to any particular business or industry, generic subdomains can be developed independently of the core domain, and can be shared across multiple applications or domains.
All this Subdomains are part of the Problem Space which is how things are in the real world.
Bounded Context:
A Bounded Context is a boundary around a specific area of the software system that defines a set of cohesive and loosely coupled capabilities.
It is a linguistic, functional, and behavioral boundary that separates one part of the system from another and defines the interactions between different parts of the system.
A Bounded Context is defined by a combination of its Ubiquitous Language, the specific business processes or requirements it is responsible for, and the technology or infrastructure it uses.
The boundary of a Bounded Context is determined by the needs of the business, and it can be adjusted over time as the business changes or as the system evolves. Within a bounded context, there is a shared understanding of the Ubiquitous Language, which is the set of terms, phrases, and concepts that are used within that context.
This shared language allows stakeholders within the context to communicate effectively and precisely about the specific concepts and processes that are relevant to their area of the system.
Bounded Contexts are important in DDD because they help to break down a complex system into smaller, more manageable parts. By defining clear boundaries between different parts of the system, developers can ensure that each part is focused on a specific set of responsibilities and can be developed and deployed independently of other parts of the system. This can lead to a more flexible, scalable, and maintainable software system.
The implementation of a Bounded Context is part of the solution space because it involves making design and implementation decisions based on the specific technical requirements and constraints of the system. These decisions may involve choices about programming languages, libraries, frameworks, data storage solutions, and other technical aspects of the system.
Context Maps
A context map is a high-level view of the relationships between Bounded contexts within a larger software system. It is a visualization tool that helps to clarify the relationships between different parts of the system and the ways in which they interact.
A context map typically includes a set of Bounded Contexts, each represented as a separate box or shape, with lines or arrows indicating the relationships between them. These relationships can include: Partnership: A partnership represents a relationship between two bounded contexts that work closely together and share a common goal.
Partnerships:
Partnerships can be bi-directional or one-way, and they may involve shared data, communication protocols, or other forms of collaboration.
Shared Kernel:
A shared kernel represents a subset of the code or data that is shared between two or more Bounded Contexts. This subset of code or data is carefully defined and managed to ensure that changes made in one context do not negatively impact the others (Vaughn Vernon advocates to avoid Shared Kernel when possible).
Customer/Supplier:
A customer/supplier relationship represents a relationship between two Bounded Contexts in which one context provides services or data to the other. The customer context depends on the supplier context, and any changes to the supplier context must be carefully managed to avoid breaking the customer context.
Conformist:
A conformist relationship represents a relationship between two Bounded Contexts in which one context adheres to the standards or protocols of the other.
The conformist context must ensure that it is compatible with the other context and does not violate its standards or requirements.
Anti-Corruption Layer(ACL):
An anti-corruption layer represents a layer of code or data that is used to translate between two contexts that have different languages or protocols. The anti-corruption layer ensures that the data exchanged between the two contexts is consistent and compatible. Context maps are useful because they help to identify potential problems or conflicts between different parts of the system, as well as opportunities for collaboration and integration. By creating a clear visualization of the relationships between Bounded Contexts, developers and stakeholders can better understand the overall architecture of the system and make informed decisions about its development and evolution.
Open Host Service (OHS):
Open Host Service refers to a relationship between two Bounded Contexts in which one context exposes a generic interface or API that can be used by the other context. This allows the second context to access and use the services provided by the first context without having to know the details of how they are implemented. OHS is useful in situations where multiple contexts need to access the same functionality, as it allows them to share a common interface and reduce duplication of effort.
Published Language (PL):
Published Language refers to the use of a common language or vocabulary between two or more Bounded Contexts. This language can be formal or informal, but it should be agreed upon by all parties involved to ensure consistency and clarity of communication. PL is useful in situations where different contexts need to exchange information or collaborate, as it helps to avoid misunderstandings and ensure that everyone is on the same page.
Another important terminology is Upstream and Downstream.An Upstream Bounded Context is one that provides input to another Bounded Context, while a Downstream bounded context is one that consumes output from another bounded context. These relationships can be thought of as a data flow, with data moving from upstream contexts to downstream contexts.
Just below a context map that illustrate the relationship between 6 Bounded Contexts(U is for Upstream and D for Downstream):
Ubiquitious language
The Ubiquitious language is a common language that is shared by the developers team and the domain experts. They both build it together, this is not only the call of the domain experts like some people may think.
This language represents all the concepts and vocabulary associated with the domain hence have to be presents in the source code too. Each Bounded Context has its own Ubiquitious Language for exemple a class in the CSS context means something completly different than in an Object Oriented context right ?
Conclusion
We saw the most well known DDD strategic patterns in this article which in my opinion the most important part of DDD. In an upcoming article we will dive into the tactical patterns of DDD Entities, Value Objects, Aggregates , Repository Patterns and more.
References