Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to understand DDD". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is DDD?

Domain-driven design was originally proposed by Eric Evans, but it has remained in the conceptual stage for many years, and there are very few projects and companies that can really be implemented and landed. However, Alibaba has really made great efforts to promote the concept of DDD, which can mainly help us solve the problem that it is difficult for traditional monolithic centralized architecture to quickly respond to business needs, and provide guidance for the prevailing scenarios of Zhongtai and micro-services.

DDD provides us with the methodology of architecture design, which is both technology-oriented and business-oriented, and grasp the design solution from a business point of view.

The role of DDD

Unified thinking: unify the understanding of the business, products and developers of the project, rather than the unity of development and products, and the unity of business and products resulting in differences.

Clear division of labor: the domain model needs to be clearly defined to solve all aspects of problems, and the team's minute understanding of these problems is formed.

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 the domain model is used to define which requirements are implemented and where to keep the structure clear.

The concept of DDD

Entity

A core domain object with a unique logo that does not change throughout the software lifecycle. This concept is similar to the Model instance that we usually deal with the database in the software model, except that these entities in DDD will contain the business logic related to the entity, which is the carrier of operation behavior.

Value object

An object attached to the existence of an entity and identified by object attributes, which packages some related entity attributes together to form a new object.

Take Chestnut as an example: for example, a user entity contains user name, password, age, address, and the address also contains attributes such as provinces, cities, and regions, and packaging these attributes into a collection of attributes is a value object.

Polymerization

Entities and value objects represent the capabilities of individuals, and our business logic is often very complex, relying on individuals can not be completed, 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, and the consistency of transactions in the same aggregation should be ensured, so the design of aggregation should be split to a minimum to ensure efficiency and performance.

Polymeric root

Also known as the root entity, a special entity, which is the manager of the aggregation, represents the entrance to the aggregation, and grasps the whole aggregation by grasping the root of the aggregation.

Domain service

The operations in some areas are verbs that cannot be simply classified into an entity or value object. After such behavior is identified from the domain, it should be declared as a service, and its role is only to provide the corresponding functionality for the domain.

Domain event

Triggered by a user action in a specific domain, indicating an event that occurred in the past. For example, the events of successful recharge and failure of recharge.

Four modes

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 behaviors are completed 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 ());}}

Anemia model

The business domain behavior is aggregated on the basis of the blood loss model, and the state change of the domain object stays at the memory level and does 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 ();}}

Hyperemia model

Responsible for the persistence of data on the basis of 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);}}

Haematosis model

Service is not needed, and all business logic and data stores are placed in one class.

For DDD, blood loss and bloating are not appropriate, blood loss is too light without aggregation, bloating that is a beginner to write code like this. So how to choose the hyperemia model and anemia model? The hyperemia model relies on the repository interface, which is closely related to data storage and has the risk of destroying the stability of the program.

Modeling method

Use case analysis method

Use case analysis is the simplest and most feasible way for domain modeling. It can be roughly divided into several steps: obtaining use cases, collecting entities, adding associations, adding attributes, and model refinement.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Get use case: extract domain rule description

Collect entities: locate solid

Add association: two entities are associated with verbs

Add attributes: get entity attributes

Model refinement: an optional step, the generalization and combination of UML can be used to express the relationship between models, and subdomains can be divided at the same time

Four-color modeling method

The four-color modeling method, which originates from "Java Modeling In Color With UML", is a method of model analysis and design, which helps the model to be clear and traceable by dividing all models into four types.

To put it simply, the four colors are concerned with the role of someone's role in a certain place and doing something with the role of something.

Event storm method

Event Storm is similar to brainstorming, which is simply who did what based on what, produced what, and affected what.

Architecture layering

Different from the traditional architecture on the left, there are some changes in the general DDD layering.

Application: includes event registration, business logic, etc.

Domain: aggregation, entity, value object

InfraStructure: infrastructure encapsulation, database access, etc.

This is the end of "how to understand DDD". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.