What is recorded here is the content of learning sharing, and the article is maintained on Github: studeyang/leanrning-share .
How to understand Domain Driven Design?
With the rise of microservices, you must have heard of domain-driven design DDD (domain-driven design), but if you look at it as a term, it seems a bit abstract. What the hell is this?
Don't worry, you must have heard of test-driven development (TDD, Test-driven development), right?
What is this concept? That is to say, in the development process, testing should be carried out first, and it is advocated to write the test program first, and then code to realize it. Development is the purpose, and testing is auxiliary, so it is called test-driven-development. We should break it down into three terms to understand.
Therefore, for domain-driven design, the design is the purpose, and the domain is the auxiliary. I want to design a software, but because the business is too complicated, the design process is difficult. At this time, use the ideas of the domain to assist the design.
How small should a microservice be?
If you were a business architect, what difficulties would you encounter during the design process? I think the first question you face is: How small should microservices be?
Some people say: "Microservices, the smaller the better!"
At this time, the operation and maintenance may jump out to beat you. If the microservices are split too much, the project complexity will be too high. Not only will the operation and maintenance of these services consume manpower, but the microservices that are too small will also occupy resources.
Is there a suitable theory or design method to guide the design of microservices?
The answer is DDD.
DDD is a design thought that deals with complex domains, including two parts, strategic design and tactical design. Strategic design is to assist in establishing a business domain model, dividing domain boundaries, and establishing a bounded context (the professional term of DDD, which will be explained below).
Tactical design starts from a technical perspective, focuses on the technical realization of the domain model, and completes software development and implementation, including the design and implementation of the microservice code architecture model.
How does the DDD idea guide the splitting of microservices? Can be divided into three steps:
The first step is to list business scenarios and find domain entity objects.
In the second step, according to the business association between domain entities, related entities are combined to form an aggregation. They belong to the same microservice.
The third step is to define multiple aggregates in a bounded context according to the semantic boundary to form a domain model. This layer of boundary is the boundary of microservices.
Thoughts in the DDD field
When studying complex domain issues, DDD will subdivide the business domain according to certain rules, which is similar to the research method of natural science.
When people encounter complex problems in natural science research, the usual practice is to subdivide the problem according to certain rules, and then conduct in-depth research on the subdivided problem subfields one by one. When all the problem subfields have been studied, we A complete knowledge system in all fields has been established.
For example: Suppose we want to study a peach tree. According to the different organs, it is divided into vegetative organs and reproductive organs, and the vegetative organs are further subdivided into leaves, stems, and roots, and the reproductive organs are further divided into flowers, fruits, and seeds.
Organs are further subdivided into tissues. To further subdivide the tissue, subdivide the tissue into cells. The cell is the smallest unit we want to study. The cell walls between cells define the boundaries of the cells and also the minimum boundaries of the study.
subregion
The peach tree is subdivided into six subfields: root, stem, leaf, flower, fruit, and seed. The sub-domains are divided according to the degree of importance, and are divided into core domains, general domains, and support domains.
The sub-domain that determines the core competitiveness of the product and the company is the core domain; there are not many personalized appeals, and the general domain is used by multiple sub-domains at the same time; it does not contain the functions that determine the core competitiveness of the product and the company, nor does it contain general A subdomain of the function, which is the supporting domain.
It should be noted that the core domain should be determined according to the company's development strategy and the actual situation of the business.
For example, if the owner of this peach tree is a gardener, then he is concerned about the peach blossoms in full bloom and the garden full of spring, so flowers are the core domain. If the owner of this peach tree is a fruit farmer, then he is concerned about the quality and yield of peaches, so the fruit is the core domain.
upper and lower limits
We know that a language has its semantic environment. In order to avoid the ambiguity of the same concept or semantics in different contexts, DDD puts forward the concept of "bounded context" in strategic design, which is used to determine the domain boundary where the semantics are located.
For example: the two accounts in the figure below, we can't distinguish them by their names alone, and we can only see the difference between them through the bounded context in which they are located.
For another example, commodities in the e-commerce field have different terms at different stages. They are commodities in the sales stage, but they become goods in the transportation stage. The same thing, due to different business fields, gives these terms different meanings and responsibility boundaries.
A bounded context can be split into a microservice, and this boundary makes a concept unambiguous within this boundary.
entity
In summary, there are four forms.
First, the business form of the entity: In strategic design, the entity in the domain model is the carrier of multiple attributes, operations or behaviors.
Second, the code form of the entity: In the code model, the form of the entity is the entity class, which contains the attributes and methods of the entity, as well as the core business logic.
DDD emphasizes "design as code". For the "flu shot" business use case, when the team discusses the business model, they say, "Nurses give patients a standard dose of flu shot."
The traditional code looks like this:
public void shot() {
patient.setShotType(ShotTypes.TYPE_FLU);
patient.setDose(dose);
patient.setNurse(nurse);
}
The code representation of DDD thinking is:
public void shot() {
Vaccine vaccine = vaccines.standardAdultFluDose();
nurse.administerFluVaccine(patient, vaccine);
}
Obviously, the second type of code is much easier to understand.
Third, the operating form of the entity: the entity exists in the form of DO (domain object), and each entity object has a unique ID. We can modify an entity object multiple times, and the modified data may be quite different from the original data. However, since they have the same ID, they are still the same entity.
Fourth, the database form of the entity: when the domain model is mapped to the data model, the entity and the persistent object are one-to-one in most cases.
value object
The value object is a basic object in the DDD domain model. Like the entity, it contains several attributes, and together with the entity, it forms an aggregation.
- The business form of the value object.
In essence, entities are tangible business objects that can be seen and touched. Entities have business attributes, business behaviors and business logic. A value object is just a collection of properties.
- The code form of the value object.
public class Person {
private Integer id;
private String name;
private Address address;
}
private class Address {
private String province;
private String city;
private String county;
}
Let's take a look at the above code. The Person entity has several single attribute value objects, such as id, name and other attributes; it also contains multiple attribute value objects, such as address address.
- The operational form of the value object.
The business attributes and business behaviors of DO objects after entity instantiation are very rich, but the objects instantiated by value objects are relatively simple.
- The database shape of the value object.
In domain modeling, we can design some objects as value objects, retaining the business meaning of the objects, while reducing the number of entities; in data modeling, we can embed value objects in entities, reducing the number of entity tables, Simplify database design.
In some scenarios, an address will be referenced by an entity, which only assumes the role of describing the entity, and its value can only be replaced as a whole. At this time, you can design the address as a value object, such as the delivery address. In some business scenarios, the address will be frequently modified, and the address exists as an independent object. At this time, it should be designed as an entity, such as address information maintenance in administrative divisions.
Aggregates and Aggregate Roots
for example. Society is made up of individuals, each of us is an individual. With the development of society, associations, institutions, departments and other organizations have gradually emerged. We have also changed from individuals to members of the organization. In the organization, everyone works together to achieve greater goals and exert greater potential. strength.
Entities and value objects in the domain model are like individuals, and the organization that enables entities and value objects to work together is aggregation, which is used to ensure that these domain objects can ensure data consistency when implementing common business logic.
If the aggregate is compared to an organization, then the aggregate root is the person in charge of the organization. The aggregate root is also called the root entity, which is not only the entity, but also the manager of the aggregate.
Between aggregates, references are associated through the aggregate root ID. If you need to access entities in other aggregates, you must first access the aggregate root and then navigate to the internal entities of the aggregate. External objects cannot directly access the entities in the aggregate.
Finally, I use the following figure to summarize the domain, bounded context, entity, value object, aggregation, and aggregation root.
the cover
related articles
Maybe you are also interested in the following article.