Before taking over the BPM work, be bosses recommended learn domain driven design, so spent a lot time reading the Eric’s the classic, many chapters turned over many times, there are many chapters are selective gave up (many of the patterns, a spade a spade really don’t understand), feel to sum up the main there are two core ideas:
- Create a unified language: Domain experts and developers discuss problems in the same language, unifying terms and concepts
- Model-driven development: Model and code are aligned
This process has gained a lot from it and found some existing problems, which are summarized here.
Why do we need domain modeling
For b-side products, the core difficulty is how to deal with the complexity hidden in the business. This complexity arises both from the business itself and from ensuring that critical “knowledge” is not lost in multiple iterations of requirements. A good way to reduce this complexity is to build a business model that simplifies and refines the complexity. This is exactly the methodology advocated by domain-driven: domain knowledge is organized through domain models, which are then used to construct more maintainable software.
In general, the determination of the model has the following advantages:
- The model allows you to project the structure of your code, so that you understand the model and get a rough idea of the structure of your code.
- The unified language of the team is formed based on the model to facilitate communication and cooperation
- Model is used as refined knowledge to reduce the cost of knowledge transmission
Effective steps for domain modeling
The advantages of the model are summarized above. How to model effectively? Eric mentioned the following five points:
- Binding of models to practices
- Propose a unified language based on models
- Develop models rich in knowledge
- Refined model
- Brainstorming and experimenting
The first two points are the basis for model refinement, while the last three points constitute a cycle of knowledge refinement. The general relationship is as follows:
I have to say that I started reading this section last year. At that time, I didn’t have enough structure to realize the importance of unified language and domain modeling. However, with many problems encountered this year, I have a deeper understanding of the benefits brought by unified language and domain modeling.
2.1 Binding of model and practice
Eric’s digest of knowledge does not focus on the good and bad models, but rather on the relationship between models and software implementations. Here’s why:
The approach advocated by knowledge digestion is essentially a trial-and-error method of iterative improvement. The initial model may not be good, but it is gradually improved through iteration after iteration, so the implementation of the correlation model and code is more important than the model is good at the time.
Another reason must be pointed out: history. At the time that Eric wrote his book, procedural programming was in vogue, and from that came two more things: the congestion model and the anemia model.
- Congestion model: The behavior and logic associated with a concept are encapsulated in the corresponding domain object, which is the knowledge-rich model emphasized in DDD
- Anaemic model: Objects encapsulate simple data, while relationships and business calculations are scattered within the scope of objects
The React Hooks API and Vue Componzition API are all about logical aggregation.
What are the elements of a specific model? The following is the mind map I made during learning. A specific domain model can be divided into multiple independent subdomains through the boundary context, and the subdomains are composed of many entities:
After building a set of models based on the above way, what we need to do is to implement our code based on the model we have designed. It should be noted that the subsequent code changes about the model need to update the model synchronously, and vice versa. Only when this is done can a true model and code binding be achieved.
2.2 Suggest a unified model-based language
Eric devotes an entire chapter in the second chapter of his book to the importance of a unified language. A unified language is a language that is shared by multiple parties within a project, and it is important to note that the parties can include all members of the project. In fact, there are many common languages in communication, such as user journeys and user portraits used between products. However, in DDD, a unified language specifically refers to a common language constructed from the domain model.
But there are problems with building a unified language based solely on models: models are essentially data structures that describe how the data will change in different business dimensions and support the corresponding calculations and statistics. Business is more about processes, interactions, rules, value generated, etc. There is a certain amount of diff involved, so if you just use the model to build a unified language, other parties don’t get the business value very well.
A better approach, therefore, is to associate models with a common language that accurately describes business value, one that places models at the heart and Bridges the generation gap.
It is also important to note that while above we emphasized the binding of model and code, here we will do the binding of model and unified language. So correspondingly, when our code changes, the corresponding unified language should also change. Only in this way can we better describe things and communicate information without generational difference.
2.3 Develop models rich in knowledge
In the domain model, there is an interesting concept called context overload: an object in the domain model plays an important role in more than one context, even as an aggregate root.
The following problems tend to occur when context overload occurs
- The objects themselves can become too complex, causing the model to become rigid and difficult to understand
- There are potential performance issues
Therefore, it is necessary to effectively separate the overloaded context. There are many ways to separate the context, and the most common one is to add context objects to isolate the model.
It’s not just context overload in the domain model, it’s the same problem in many other domains.
First of all, we need to make clear that the fundamental problem of context overload is that entities play multiple roles in different contexts, and then through aggregation relationships, the logic in different contexts is enriched in entities, resulting in context overload.
So we can separate the responsibilities of a single large entity by separating different contexts and adding live objects.
2.4 Refining model
When we separate models, there is a methodology for separating large models. However, there is another issue that needs attention during development: how do you organize domain logic and non-domain logic so that non-domain logic does not contaminate the model? This is where layered architecture comes in. Layered architecture can be said to exist in every aspect of the software development field, small to components, large to computer networks, there are ideas of layered architecture in it. Its purpose is simple: encapsulate the logic of different concerns into different layers.
In domain-driven design, we can usually divide the system into four layers, based primarily on the fact that requirements change at different rates between layers:
- Presentation layer: human-computer interaction
- Application layer: responsible for supporting specific business and organizing business logic into software functions
- Domain layer: core domain concepts, information, and rules.
- Infrastructure layer: Provides common technical capabilities
Of course, the infrastructure layer is not necessarily necessary, and we can also simplify the layer through something like the capability provider model.
2.5 Brainstorming and experimentation
Through these steps, we were finally able to bring the model and the unified language directly to the business. So how do we refine our model by honing it in the business.
Before discussing this, we can first understand a modeling method: event modeling, which captures the changes of information in the system through events, explores the sources of these changes, and then discovers the entities and operations behind them, and finally completes the modeling of the system. So how do we model events:
- Interactions are represented by events. There are two main difficulties here: 1. Integration into the domain model; 2
The main problem with the first point is that the business relationship is about user behavior, while the model is about data. There is a gap between the two, and the event is the bridge. We can think of events as imprints of behavior. The time of the event is the most important attribute of the event. When an event occurs, there may be a change in data.
- Divide events by timeline. In fact, this principle answers the second difficulty mentioned above.
The overall process of event modeling has the following five steps:
Here are also a few nouns that need to be explained:
- Actor: the user of the system. (This could be a real user, or it could be another system)
- Command: An action initiated by an actor that represents a decision, usually the cause of an event, also known as an action or punishment command
- Aggregation: An aggregation of domain-driven designs, which can be seen as a set of domain objects that refer to certain domain concepts in the brainstorming phase without elaboration.
- System: Refers to a tripartite system that requires no details
- Reading model: Information used to support decisions, usually related to interface layout
- Policy: a response to an event, usually indicating a logic that does not belong to some aggregation. A policy can trigger a new command, and a command triggered by a policy is called a system-triggered command.
By building the model through event modeling, we can converge events through continuous event storms and practices, so as to improve our model.