Domain-Driven Design — Strategic Design
Introduction
The first step in DDD is understanding problem space. It is the procedure to analyse the project strategically and in high-level manner regarding the constraints of business domain.
The strategic aspect of DDD deals with answering the questions of “what?” and “why?” — what software we are building and why we are building it.
Strictly speaking, the constraints and requirements of business domain should be considered in Strategic Design.
To perform the Strategic Design we have to understand its portions or steps. These parts act as four key pillars as below:
- Business Domain Analysis
- Ubiquitous Language
- Bounded Context
- Context Map
Business Domain Analysis
A company presents itself to the market with its business domain. As a matter of fact, it is the main activity of firm and also the services that it can offer to the clients.
Some firms are active in only one business domain, like DHL, DPD and so on. On the other hand, some companies have more than one, like Amazon that offers retail and also cloud computing services (AWS).
Because the business domain is the coarse-grained and end-goal of company, it has to be divided to subdomains to achieve the company goals.
The note is that to satisfy company goals all subdomains together must be functional and act as an active member of this orchestration.
Domain-Driven Design distinguishes between three types of subdomains:
- Core Subdomain
- Generic Subdomain
- Supporting Subdomain
Core Subdomain
The company is distinguished by its core domains and these domains can be defined as the heart of business. For example in a company that produces firewall, the core domain is the packet processing module, policy engine and so on that depicted in orange block in figure above. These domains can differentiate the firm from other competitors.
Core Subdomain is the most complex domain in DDD and is developed in company and maintained by in-house developers. It should not be outsourced or be bought from other providers.
Core subdomains, by themselves , can not solve any problem and provide any service to the clients.
Generic Subdomain
Generic subdomains are business activities that all companies are performing in kind of similar way. From technical point of view, these subdomains are very complex to implement and it is not suggested to be implemented by company.
Authentication and authorisation of users is an example of Generic Subdomain. Another example is the firewall that needs DPI engine to inspect packets. There are many companies that offer DPI engine and because of complexity it is proposed to use the products in the market. In the figure above, the generic subdomains are depicted in blue.
Remember that these subdomains do not have any competitive advantages. That's why, beside complexity of implementation, it should be ordered to 3rd parties or providers.
Supporting Subdomain
In contrary to the other two subdomains, Supporting Subdomains are simple and can be outsourced to develop and maintain.
For example in the mentioned firewall, there are many supporting subdomains that are defined also as feature for software, Like IPS, DLP and so on. These features can be and better to be outsourced to the 3rd parties. They are depicted as yellow components in the figure above.
Ubiquitous Language
During developing a software, from costumer requirements management to launching to the market, each party and domain has its own language to communicate inside the team. For example the definition of word 'pattern' could be different in development team from domain experts.
In this case that each party has its own understanding and definition from the same word or expression, it is necessary to have a common language between all parties to facilitate communication. Otherwise, the parties must translate the incoming messages from others to be understandable, useable and parsable in their boundary (group, domain or team) to have an efficient and performant workflow.
This common language is called Ubiquitous Language. By using this language between parties, there is no any need to make an assumption about business requirements and all ambiguities MUST be eliminated.
Instead of continuously translating domain knowledge, Domain-Driven Design calls for cultivating a single language for describing the business domain: the Ubiquitous Language.
Bounded Context
As described, the ubiquitous language is the common understanding from business domain between all parties in a firm or company. But some parties have more complexity by itself than the others.
For example in our firewall, the definition of AI/ML in development team is much more complex than marketing team. To follow the definition of ubiquitous language, we have to simplify the development or bring the complexity of development to the marketing team. In first case, the business goals won't be achieved and in second case, the unnecessary complexity is imposed to the marketing team.
To solve this problem, the ubiquitous language MUST be defined in an explicit boundary and in more fine-grained context.
On the other words, ubiquitous language should be divided into smaller languages that are specifically understandable inside that boundary. The name of this boundary is Bounded Context that defines the scope of ubiquitous language.
Bounded Context completes the definition of ubiquitous language. The note is that to have it functional and efficient, we should not define it as a universal language.
The wider the boundary of the ubiquitous language is, the harder it is to keep it consistent and the smaller they are, the more integration overhead the design induces.
Ideally, each Bounded Context has its own ubiquitous language that doesn't have any overlap with other bounded contexts. But in real world it is necessary for each of them to communicate with outside of the boundary and exchange information properly.
Context Map
A language in its boundary (Bounded Context) models an specific business domain. Furthermore, each bounded context needs to communicate with others and understand them in a proper way.
The relationship between these business domains (bounded context) is called Context Map that in this section we learn the most useful patterns of it.
Partnership Pattern
In this way of communication, the two bounded context have a close relationship with together. On the other words, they have bidirectional cooperation and are dependent to each other.
Shared Kernel Pattern
Shared Kernel Pattern is used if a part of subdomain is implemented in multiple boundaries (bounded contexts) or we are using the shared code among subdomains for whatever reasons like avoiding code duplication and applying DRY principle.
Conformist Pattern
This pattern is the first Customer-Supplier pattern out of three in our list.
When a subdomain (upstream) does not have any interest to accept the communication constraints of other subdomains (downstream) for conversation, the downstream (Customer) MUST adapt itself with the conditions of upstream.
If the downstream subdomain adapt itself with upstream one, the communication pattern is conformist.
Anticorruption Layer Pattern
This pattern is the second Customer-Supplier pattern out of three in our list.
In this case, the downstream subdomain instead of conforming to the upstream bounded context, provides a layer to translate upstream context to facilitate communication with its own domain model.
The mentioned layer that is used by customer subdomain as intermediary layer, is Anticorruption Layer or ACL. It is proposed to use ACL if the downstream party is a core subdomain or upstream bounded context is a legacy domain that conforming to it is not practical.
Open-Host Service Pattern
This pattern is the third Customer-Supplier pattern out of three in our list.
In this case, the upstream subdomain (supplier) decouples its implementation model from the public interface to protect the customer from changes in its implementation model by Open-Host Service Pattern or OHS.
The other definition or newer explanation of OHS is application programming interface (API).
Real World Scenario
Typically both OHS and ACL are used in the two sides of communication channel by customer and supplier. In our scenario, supplier is exposing its language by OHS with expression of RESTful API. On the other side, customer side, ACL receives the messages and commands and translate it to the language that is know and understandable by customer.
The described workflow happens exactly on the other direction too, that customer wants to communicate with supplier.
