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

This article focuses on "how to understand the concept of domain-driven design". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the concept of domain-driven design.

Eric Evans published "Domain-driven Design-the solution to Software Core complexity" in 2003, and put forward the software business architecture division methodology of DDD, which has become the theoretical guidance of today's micro-service split. Then Vaughn Vernon published "implementing Domain-driven Design", as well as subsequent geek time and gitchat articles about this, but all of them are theoretical. So far, we have not heard of open source projects that fully implement the idea of DDD. Generally, C# and Java are used as examples. DDD is not like MVC, most people can divide very clearly, and the same. In my opinion, everyone understands DDD, and combined with actual projects, different domain divisions will be drawn according to the understanding of technical architecture, business architecture, and domain-driven design.

To borrow an article by Meituan:

The current architecture is controller, service, dao, vo entity layer. Vo is just a simple data carrier. There is no problem for a simple business system to adopt this anemic model and process design, but when the business logic becomes complex, the business logic and state will be scattered in a large number of methods, and the original code intention will gradually become unclear. We call this situation amnesia caused by anaemia. The hyperemia model of the domain-driven design defines the functions of the important domain of the module and stipulates that the basic service cannot call the upper-level methods in reverse.

1. Basic concept

DDD is an improvement of object-oriented design and a method of developing complex business logic. It helps to guide the decomposition of applications into services, and each micro-service has its own domain. If you want to use DDD flexibly to design, you need to know the terms and concepts he put forward.

1. 1 domain domain, subdomain, and bounded context

Domain: it can be represented as either the entire business system or its core domain (core domain) or subdomain.

Subdomain: the split part under the realm

Bounded context: the subdomain is the question space, and the bounded context is the answer space. Different subdomains have different meanings in different fields. The upper and lower boundaries are used to delineate the boundaries of the field.

1.2 Domain Services domain service, Application layer

Application layer: corresponds to the controller or API interface in development.

Domain services: deal with the business logic of the domain and implement business logic objects that do not belong to entities or value objects

1.3 aggregate aggregate, aggregate root aggregate root, entity entity, value object value object

Aggregation: there are multiple aggregations in a domain, which is a cluster of domain objects within a boundary, consisting of root entities and possibly one or more other entities and value objects. Reference aggregations must be represented by the

Aggregation root: a class with a unique ID in the application that contains entities and value objects based on the identified aggregations. The life cycle of the object in the aggregation is consistent with the aggregation root, such as the order and the order details, which is generally the relationship of 1Rom n. The order is used as the aggregation root, the order is deleted, and the order details are also hung up.

Entities: there is a unique ID internally, and two entities with the same attributes are still different objects

Value object: an attribute of an entity, or an object of a collection of values. Value objects with the same attributes can be interchanged. For example, the value object is money, which consists of currency and amount. Money objects of the same currency and amount are equivalents.

1.5 Warehouse repository

The object used to access the persistent aggregation root is simply the CRUD at the aggregation root level. Database-related classes in spring also end in repository.

1.6 Infrastructure infrastructure

Commonly used tool class, underlying database persistence

1.7 Factory factory

Put the complex process of aggregation root generation into the factory class to implement

two。 Core thought

The core idea of domain-driven design is obviously the division of domains. Transactions in the domain also need to be considered.

3. Implementation of Java landing

Https://tech.youzan.com/dddclue/ has a relatively complete business analysis process and implementation.

There are likes to divide the package module like this.

Combined with the simple understanding of the project, the structure of the transformation package is as follows:

Infrastructure: put in the existing dao layer and util

The repository:save method passes in the aggregation root and no value is returned. How to disassemble root into vo and persist the data is implemented in save.

4. CQRS

CQRS (Command Query Responsibility Segration), the separation of command and query responsibility, that is, the separation of read and write, distributes the read and write to different classes for processing at the code level, and the read can interact directly with the database. This framework tells you that even CRUD can be very complicated. The technical architecture of read-write separation developed as a domain-driven design also has a set of basic elements.

Command bus: distribute multiple command to the corresponding command handle for processing

Event source: trace the source of events and keep the history of aggregate CRUD, which is very helpful for the implementation of design and regulatory functions

Event bus: event bus that writes event to the database asynchronously

Command handle: working with command

Query facade: query facade, package data as DTO, and remove redundant attributes (such as identification bits, creators, etc.)

The lower read-write separation model is simplified and the message component event bus is omitted.

Implement simple CQRS

The existing Axon framework designs CQRS frameworks such as DDD according to the idea of CQRS.

5. Domain-driven design is not a silver bullet. At present, the mainstream methodologies in the market are

OOA/OOD/OOP object-oriented analysis, design and methods, usually modeled and described by UML

ER modeling, that is, data-driven development, according to the business design database table structure for development

DDD domain-driven design

Four-color modeling, developed by The Open Group, published the TOGAF architecture framework in 1995. It is composed of four elements: (1) time-time prototype (Moment-Interval Archetype), (2) participant-place-object prototype (Part-Place-Thing Archetype), (3) description prototype (Description Archetype), and (4) role prototype (Role Archetype).

Few domestic companies will strictly follow the domain-driven design methodology, high learning cost, it is often difficult to obtain its essence. In fact, according to the situation of the business and the team, some concepts of Emurr diagram, UML and DDD are often used to analyze and design the business architecture. The mainstream MVC architecture does achieve the decoupling of view, business and data, but the VO is an anaemic model (only get and set methods of attributes and objects), and the writing of business code is also process-oriented. Domain-driven design said: this pattern is only suitable for business is complex and changeable enough, if the simple business logic, forced application of DDD will overdesign, resulting in simple problems complicated, contrary to the original intention of DDD to simplify complex business.

6. Summary

The advantages and disadvantages of domain-driven design are very obvious.

Shortcoming

Learning cost, team awareness requirements, need to be highly abstract of the business

It takes a lot of time for domain experts and technicians to understand the unified domain language, which deviates from the popular agile development of Scrum.

Due to the complexity of business change, it is necessary to identify changeable business for domain modeling, resulting in "lack of design" and "over-design".

Advantages

Reasonable application methodology can abstract and decouple the system.

Complex business divide and conquer

How to use

First of all, judge whether the business is complex and changeable enough and build a relatively stable model.

Basic components such as domain division, online text on the boundary, etc.

In short, excellent designs are produced after a large number of running-in iterations with the business, how to define complexity and domain or to communicate with domain experts. Reference books and materials include "Micro Service Architecture Design pattern", "Software Architecture Design-the way to integrate the Technical Architecture of large websites with Business Architecture", two divine books on domain-driven design, my ideas, and a good technical blog.

At this point, I believe you have a deeper understanding of "how to understand the concept of domain-driven design". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.