A domain model is a visual representation of a conceptual class or real-world object within a domain. Domain models are also known as conceptual models, domain object models, and analysis object models.

— UML and Pattern Application

In daily development, we often argue about some function points, “this function should not be changed by me, it should be changed by your side”. Finally, after being compromised and changed, we don’t understand why this function should be changed by our side. Unlike traditional architectural design, domain-driven design (DDD) may help you achieve a clear division at this point.

What is the DDD

Domain driven design was first put forward by Eric Evans, but over the years has been to stay in the concept stage, the real implementation and little landing project and company, and come in ali internal actually in push forward the concept of DDD, it can help us to solve the traditional main monomer type architecture focus is difficult to quickly respond to business requirements fall to the ground, And provide guidance for the middle stage and microservices prevailing scenarios.

DDD provides us with a methodology for architectural design that is both technology-oriented and business-oriented, taking design solutions from a business perspective.

The effect of DDD

Unifying thought: unifying the cognition of business, product and development of all parties in the project, instead of unifying development and product, business and product, resulting in differences.

Clear division of labor: The domain model needs to be clearly defined to address the various aspects of the problem and to develop a team minute understanding of these issues.

Reflect change: Requirements are constantly changing, so our model is constantly changing. The domain model can truly reflect these changes.

Boundary separation: The domain model is separated from the data model and used to define which requirements are implemented and where, keeping the structure clear.

The concept of DDD

entity

A core domain object that has a unique identifier that does not change throughout the software lifecycle. This concept is similar to the Model instances that we normally deal with in software models and databases, except that in DDD these entities will contain the business logic associated with the entity, which is the carrier of operational behavior.

The value object

Attached to the entity, the object is identified by object attributes, which package some related entity attributes together to form a new object.

For example, a user entity contains a user name, password, age, and address. The address in turn contains attributes such as province and city, which are packaged into a set of attributes called value objects.

The aggregation

Entities and value objects represent the capabilities of individuals, but our business logic is often very complex and cannot be completed by relying on individuals. At this time, multiple entities and value objects need to work together, and this collaborative organization is aggregation. Aggregation is the basic unit of data modification and persistence. To ensure the consistency of transactions within an aggregation, the design of aggregation should be split to a minimum to ensure efficiency and performance.

Aggregate root

Also known as the root entity, a special entity that acts as the manager of the aggregation and represents the entrance to the aggregation, capturing the root of the aggregation captures the entire aggregation.

Field service

Some fields of operations are verbs that cannot be easily grouped into an entity or value object. Once such behavior has been identified from the domain, it should be declared as a service whose sole purpose is to provide functionality for the domain.

Field events

Triggered by user actions in a particular domain, representing events that occurred in the past. For example, recharge successful, recharge failed events.

Four patterns

Blood loss model

In the model, there is only a simple GET set method, which is the simplest encapsulation of an entity, and all other business activities are done by the service class.

@Data @ToString public class User { private Long id; private String username; private String password; private Integer status; private Date createdAt; private Date updatedAt; private Integer isDeleted; } public class UserService{ public boolean isActive(User user){ return user.getStatus().equals(StatusEnum.ACTIVE.getCode()); }}Copy the code

Anemia model

The business domain behavior is aggregated on the basis of the blood loss model, and the state changes of domain objects remain at the memory level and do not care about data persistence.

@Data @ToString public class User { private Long id; private String username; private String password; private Integer status; private Date createdAt; private Date updatedAt; private Integer isDeleted; public boolean isActive(User user){ return user.getStatus().equals(StatusEnum.ACTIVE.getCode()); } public void setUsername(String username){ return username.trim(); }}Copy the code

Congestion model

Be responsible for data persistence based on anemia model.

@Data @ToString public class User { private Long id; private String username; private String password; private Integer status; private Date createdAt; private Date updatedAt; private Integer isDeleted; private UserRepository userRepository; public boolean isActive(User user){ return user.getStatus().equals(StatusEnum.ACTIVE.getCode()); } public void setUsername(String username){ this.username = username.trim(); userRepository.update(user); }}Copy the code

Expanding blood model

Services are not required. All business logic and data stores are placed in one class.

For DDD, blood loss and swelling are not appropriate, blood loss is too light without aggregation, swelling that is a beginner to write code like this. So how to choose between hyperemia model and anemia model? The congestion model relies on the Repository interface, which is closely related to data storage and risks destabilizing the program.

The modeling method

Use case analysis

Use case analysis is the simplest and most feasible way to model a domain. It can be roughly divided into obtaining use cases, collecting entities, adding associations, adding attributes, and refining the model.

  1. Get use cases: Extract domain rule descriptions

  2. Collect entities: Locate entities,

  3. Add association: Two entities are associated with a verb

  4. Add attributes: Get entity attributes

  5. Model refinement: An optional step to express relationships between models using UML generalizations and compositions, as well as subdomain partitioning

Four color modeling method

Derived from Java Modeling In Color With UML, four-color Modeling is a method of model analysis and design that helps make models clear and traceable by dividing all models into four types.

To put it simply, four colors focus on the character of someone in a place doing something with the character of something.

Event storm method

Event storms are similar to brainstorming, in a nutshell, who did what, when, based on what, produced what, and affected what.

Architectural layering

There are some changes to DDD layering as opposed to the traditional architecture layering on the left.

Application: contains event registration and business logic

Domain: aggregate, entity, value object

InfraStructure: InfraStructure encapsulation, database access, etc

conclusion

DDD is a set of perfect methodology, which can help us to design the system architecture reasonably. At the same time, a good template should be constantly adapted to change, and DDD can also help us to support the business development more quickly and conveniently.