Let's build something awesome together
Send Your CV to us and we will call you!
Let's build something awesome together
Send Your CV to us and we will call you!
Domain Driven Design (DDD): three letters that make big difference
19.08.2021
Any Angular developers who use Monorepo know that it allows large enterprise applications to subdivide into small maintainable libraries. This ability unties your hands, making decisions more flexible and constructive. Obviously, your first step is defining the separation criteria and declaration of the communication rules between them.
Today, we will consider strategic design to slice massive software systems using the Domain Driven Design(DDD) approach.
What is meant by Domain-Driven Design (DDD)?
First of all, this concept connects the structure and language of software code with business domain needs. In other words, DDD is a set of rules that enable you to make the right design decisions. The main advantage of the DDD approach is smoothing the contradictions between complex software systems and appropriate application design. DDD allows to dramatically speed up the software design process in an unfamiliar domain. According to DDD, you may use the strategic and tactic design. Suppose the tactical design has clear views on using OOP and implies using concrete concepts and patterns for object-oriented design or architecture. Instead, the strategic design proposes dividing the extensive system into the structure of the individual (sub-) domains and their design.
Searching for Self-contained Domains with Strategic Design.
If you choose the Strategic design approach, you should identify self-contained domains. Also, you need to identify the common vocabulary of these domains, which both developers and domain experts must use to avoid misunderstanding. Please, note, vocabulary actually is the ID of these domains. Thus, the code uses this language, and application as a consequence is more self-describing. In DDD, it's calling ubiquitous language. As you can guess, another characteristic of the domain is the number of expert groups that interact with it.
Obviously, you should take a look at the production process in the system at first. Let's try to identify a domain by its processes. For example, let's assume the domain of raw materials procurement for any kind of production: 
What exactly do we see? Most of the process, better to say, all steps of the process Approve Order, Request Budget, and Approve Budget belongs to organizational hierarchies and the available budget when the production process primarily concerns employees and products.
Let's not be charmed by the magic of the term product and take a look closer. We can see that product is not the same thing in all steps of production. The product has been described in every detail in the catalog, but for approval, you need a few critical data: 
Sure, you have to separate these two forms of a product using ubiquitous language, realizing where it prevails in each domain. You must create the ultimately concrete and valuable models full of sense. Thus, you avoid many problems with a single complicated and disconcerting model with an unrealizable goal to describe everything.
Despite that, these models have too many interpenetrations and interdependencies, so slicing and subdividing are not sims to be pretty straightforward. But you are still able to make your personal attitude at a logical level. Be sure that the same ID on both sides expresses the same, and it will work without technical dependencies.
So, we have to conclude that each model can be appropriate for only specific scope. In the DDD concept, it is called the bounded context. The bound context belongs to each domain in ideal conditions. As practice shows, this is not always an achievable goal in the shape of integrating third-party systems. Let's move ahead and find the following domains: 
It's not hard to grasp that the process-oriented approach ensures the creation of hierarchically organized control programs that naturally reflect the eventfulness, synchronism, and parallelism inherent in control algorithms. Structural correspondence of the created programs to the target technology, in turn, contributes to the simplicity of the development of control programs for their further maintenance into the autonomous domains while keeping close relations.
What exactly do we see? Most of the process, better to say, all steps of the process Approve Order, Request Budget, and Approve Budget belongs to organizational hierarchies and the available budget when the production process primarily concerns employees and products.
Let's not be charmed by the magic of the term product and take a look closer. We can see that product is not the same thing in all steps of production. The product has been described in every detail in the catalog, but for approval, you need a few critical data: Sure, you have to separate these two forms of a product using ubiquitous language, realizing where it prevails in each domain. You must create the ultimately concrete and valuable models full of sense. Thus, you avoid many problems with a single complicated and disconcerting model with an unrealizable goal to describe everything.
Despite that, these models have too many interpenetrations and interdependencies, so slicing and subdividing are not sims to be pretty straightforward. But you are still able to make your personal attitude at a logical level. Be sure that the same ID on both sides expresses the same, and it will work without technical dependencies.
So, we have to conclude that each model can be appropriate for only specific scope. In the DDD concept, it is called the bounded context. The bound context belongs to each domain in ideal conditions. As practice shows, this is not always an achievable goal in the shape of integrating third-party systems. Let's move ahead and find the following domains: It's not hard to grasp that the process-oriented approach ensures the creation of hierarchically organized control programs that naturally reflect the eventfulness, synchronism, and parallelism inherent in control algorithms. Structural correspondence of the created programs to the target technology, in turn, contributes to the simplicity of the development of control programs for their further maintenance into the autonomous domains while keeping close relations. Context Map as a tool to provide interaction
Various domains, despite their individualism and autonomy, must have an effective and reliable interaction system. The Ordering domain has access to both the Catalog and Enterprise Resource Planning (ERP) domains, as is shown in the following diagram. 
A context map determines how these domains interact. In principle, Ordering and Booking could share the common model elements. In this case, however, we must ensure that modifying one does not cause inconsistencies.
The Context Map task is to determine the way these domains interacting. Theoretically, they can share common model elements, and the Content Map defines and ensure that any modification will not acquire incorrectness.
However, the described model does not answer the question of how much power each of the domains is entitled to in condition of the easy use of the other.
Strategic design defines the next strategies for the relationship between consumers and providers.
The definition of the next strategies for the relationship between domains is the goal of the strategic design. Let's go back to the diagram. Catalog, via API, offers a tool to prevent changes that may cause the forcibly affecting consumers. The ERP system uses an anti-corruption layer (ACR) for access. It's happening because the order is not affected much on the ERP. The simple system update will activate any changes.
As shown in our example, the bounded context idea is usually not the one and only for the existing systems ERP. In fact, it unites some logical and intermingled sub-domains. For obvious reasons, it is much more rational and convenient.
Seemingly, a bounded context is a must requirement for each domain, but there are exceptions. An existing system might contain several bounded contexts not isolated from each other.
A context map determines how these domains interact. In principle, Ordering and Booking could share the common model elements. In this case, however, we must ensure that modifying one does not cause inconsistencies.
The Context Map task is to determine the way these domains interacting. Theoretically, they can share common model elements, and the Content Map defines and ensure that any modification will not acquire incorrectness.
However, the described model does not answer the question of how much power each of the domains is entitled to in condition of the easy use of the other.
Strategic design defines the next strategies for the relationship between consumers and providers.
The definition of the next strategies for the relationship between domains is the goal of the strategic design. Let's go back to the diagram. Catalog, via API, offers a tool to prevent changes that may cause the forcibly affecting consumers. The ERP system uses an anti-corruption layer (ACR) for access. It's happening because the order is not affected much on the ERP. The simple system update will activate any changes.
As shown in our example, the bounded context idea is usually not the one and only for the existing systems ERP. In fact, it unites some logical and intermingled sub-domains. For obvious reasons, it is much more rational and convenient.
Seemingly, a bounded context is a must requirement for each domain, but there are exceptions. An existing system might contain several bounded contexts not isolated from each other. Separate Ways strategy
Sometimes we are faced with needless at first sight dubbing of the calculating specific task, which is implemented simantenously and separately in several domains; the VAT calculation, for example. 
The only and sufficient reason to generate redundant code is limiting dependencies. Each of the dependencies is a contract, and the contract is difficult to change. You should always sacrifice something less to achieve something more. This is precisely the case.
In conclusion, let us briefly highlight the main points:
The only and sufficient reason to generate redundant code is limiting dependencies. Each of the dependencies is a contract, and the contract is difficult to change. You should always sacrifice something less to achieve something more. This is precisely the case.
In conclusion, let us briefly highlight the main points: - Strategic design is an approach to identifying self-contained domains or subdomains, ubiquitous languages, and concepts that belong and make sense in the domain's bounded context only.
- Context map shows the ways how those domains are interacting.