Summary Domain Driven Design Domain-Driven Design knowledge DDD

It is like the first time I read objective java, I realized what code quality is. The first time I came into contact with Domain Driven Design, I began to understand what design was. In my previous blog, I shared 12 classic e-books, including java, OO design, spring, hibernate, struts2, and agile, where I downloaded the DDD book.

Domain Driven Design is based on some simple, important, and pragmatic ideas. Next we will summarize the basic theories of DDD based on our own understanding.

1. Profound Understanding of Domain knowledge

DDD emphasizes domain-based design. The premise is to have a deep understanding of domain knowledge and need continuous learning. Another related practice is ubiquitous language ). The terminology used by domain experts is accurate. This term should also be used when programmers discuss domain-related issues. This term is also used when writing code. The advantage of doing so is that we can map the domain stuff to the code and keep the code reflecting the domain.

 

2. Layered

Layered Architecture

The program needs to be layered. This is a simple truth, but it needs to truly form consciousness.

Let's talk about the four layers involved in Domain Driven Design.

2.1 Infrastructure Layer

It mainly provides technical support for the above layers. For example, message transmission and persistence. The UI Layer can also be divided into more basic component as the infrastructure layer.

2.2 UI Layer

The UI Layer displays information and explains user input commands. What's important is that the UI Layer does not have domain knowledge.

2.3 application Layer

The role of the application layer is to describe the external functions of the product, which can coordinate the interaction between the UI and the Domain layer.Application layer should be thin. It does not have domain knowledge.

2.4 Domain Layer

The Domain layer is the most important layer. Encapsulate all business logic.

 

DDD also breaks down software from another perspective. A building block includes association, entity, value object, service, and module. The emphasis is on entity. value object and service. service are easier to understand. Generally, they are stateless. It can exist in the application layer, domain layer, or infrastructure layer. It is not easy to distinguish between entity and value object. entity, which emphasizes its id rather than its attribute. It emphasizes the continuity and identity of its life cycle, andValue object is used to "describe" entity. Value object is suitable for immutable in many cases. Note that if you use hibernate, you will know that the value object in hibernate usually cannot reference multiple entity. In other words, the object that can reference multiple entity is usually entity. in the DDD theory, the "Route" is a value object. It can reference the city (entity) and highway (entity) of the "Route ).

 

3. Domain Object Lifecycle

An important theory of DDD is that if the relationship between aggregate. domain objects is very complex, inconsistency may occur when domain knodge DGE involves complicated rule. The solution is to put some domain objects in a group and use a domain object as the root (aggregate root). All accesses to these domain objects must use this aggregate, so the work to maintain consistency is limited to this aggregate root.

 

Another related theory is that factory and repository. factory are used to "CREATE" objects and are a process from scratch. The repository is used to retrieve objects. That is to say, objects exist objectively but are not stored in the memory. The repository is used to extract data from a certain place (usually a database) and construct is used as objects. A common design is to expose the retrieve and create APIs to the repository, but the specific work proxy of create is used by the factory. That is to say, the factory is usually aggregated in the repository.