preface
Shortly after joining Ali recently, I found that most of the internal projects adopt DDD design. Since I did not have too much contact with them before, I took some time to learn about them, during which I also read the article of big Brother Fei. Today, on the first day of the Chinese New Year, I will simply talk about my DDD learning and sharing.
What is DDD
DDD: Domain-driven Design
Driven domain design is a software development approach that addresses complex requirements by connecting implementations to continuously evolving models. Put that way, it might sound vague. In simple terms: to solve the complexity of the business.
1.1 Prerequisites:
Since it is to solve the complexity of business, it must be used in complex business, so DDD should also have a certain premise to use it.
-
Put the main focus of the project on the core domain and domain logic
-
Placing complex designs on a bounded context model
-
Initiate a creative collaboration between technical and domain-bound experts to iteratively refine conceptual patterns to solve domain-specific problems
Domain-driven design is an idea that the system design is driven by the domain model, not by storing data dictionaries (DB table fields, ES, Mapper fields, etc.). Domain models are abstractions of business models, and DDD is a way of translating business models into system architecture designs.
1.2DDD Three-Tier Architecture:
-
API: The API layer is used for external packaging, front-end interface calls. Domian layer is the whole Domain model, it can not be directly packaged into Maven for others to use, nor can it be directly used as an interface to the front end, some need API layer as the call Domain after transformation, the data returned by the call Domain for packaging and screening and then returned out.
-
Domain: The core layer of the system. All specific business logic processing and event processing are processed in this Domain model.
-
The Repository: Data source proxy layer: The Repository layer is similar to a gateway proxy. It has no data and is accessed by the Domain layer through its proxy. The proxy data source can be not only DB and ES but also HTTP and RPC.
1.3 Service Understanding
Now that you know DDD, you know how it works; So for a business system, how to conduct DDD modeling design and domain model division is the most important.
Only by fully understanding the business and sorting out every detail of the business can business models be effectively transformed into domain models.
Let me take an e-commerce system as an example to conduct a simple domain analysis
E-commerce system is the most common one in our life. Goods, orders, transactions, distribution, and so on, each subsystem is extremely complex.
- Commodity picture, commodity name, commodity price
- Commercial activities
- Freight, delivery information, etc
Sorting out business: Each specific point of the business will be listed in the process of sorting out business. By abstracting the understanding of business, related business points are grouped and aggregated. The process of business abstraction involves boundary division, for example, should commodity price information and commodity activity price information be abstracted into commodity basic information or commodity basic information and commodity marketing information respectively? In the commodity business, a product can take part in several activities, the goods under the basis of all marketing activities are the same commodity information, but the goods of each marketing information can be different, can be free shipping cost, also can is filled with xx xx) reduction, in the commodity business commodities based information and marketing information is need to abstract into two independent business module.
Model transformation: Once we have combed through the business and performed a simple business model split, we can map the business model to the domain model through a simple translation.
What is Cola?
Cola is an open source framework for Alibaba, which is the implementation of DDD.
It advocates taking business as the core, decouples external dependencies, and separates business complexity from technical complexity.
Helping applications “move from clutter to order” is what the COLA architecture was designed for. Its core responsibility is to define a good application structure and provide best practices.
2.1 Layered structure of COLA:
-
Adapter Layer: responsible for routing and adaptation of front-end display (Web, Wireless, WAP). For traditional B/S system, Adapter is equivalent to controller in MVC.
-
The Application Layer is responsible for obtaining input, assembling context, verifying parameters, calling the domain Layer for business processing, and sending message notifications if necessary. The layer is open, and the application layer can bypass the domain layer and directly access the basic implementation layer.
-
Domain Layer: it mainly encapsulates core business logic and provides business Entity and business logic calculation for App Layer through Domain Service and Domain Entity method. The domain is the core of the application, independent of any other level;
-
Infrastructure Layer: mainly deals with technical details, such as CRUD of database, search engine, file system, RPC of distributed service, etc. In addition, the burden of Domain preservation falls here, as external dependencies need to be escaped by the Gateway before they can be used by the App and Domain layers above.
2.2 Cola subcontracting structure:
- COLA Architecture: Focus on the definition and construction of application architecture to improve application quality.
- COLA components: Provide reusable components for application development to improve r&d efficiency.
2.3 Quick use of COLA
COLA open Source address: github.com/alibaba/COL…
Third, thinking about DDD
There is no absolute right or wrong for design domain models. The domain model that best fits your business system is the best. In the process of DDD learning, I have been thinking about how I should design.
Like in an e-commerce system, it can actually be “horizontal DDD”
It can also be “longitudinal DDD”
This article is some of their own learning understanding, if there is wrong, you can correct, common progress.