field
Domain-driven design
DDD emphasizes that it is necessary to understand the data, processes, rules, etc. involved in the "domain", and then build a model (that is, the domain model) for it from an object-oriented point of view, and this model, It determines what technology, what architecture, and what platform you will use to implement this system. Therefore, technology is "passive" in this process and is "selected" to realize the "domain model". For the success or failure of the project, technology is not the decisive factor, whether the domain model conforms to the essence of things is the key.
It can be seen that the starting point of domain-driven design is business orientation, and technology serves business.
entity
For example, a product is an entity in the product context, which is identified by a unique product ID. No matter how the data of the product changes, the product ID remains unchanged, and it is always the same product.
value object
Entity is a real business object that can be seen and touched. Entity has business attributes, business behavior and business logic. The value object is just a collection of several attributes, only data initialization operations and limited behaviors that do not involve modifying data, and basically does not contain business logic. Although the attribute set of the value object is physically independent, it is still a part of the entity attribute logically, and is used to describe the characteristics of the entity. There are also some shared standard types of value objects in value objects. They have their own bounded contexts and their own persistent objects, and they can create shared data microservices, such as data dictionaries.
For example, the user's address is designed as a value object - the address is part of the user's attributes, which includes the country, province, city, district, street, etc.
aggregate/aggregate root
If the aggregate is compared to an organization, then the aggregate root is the person in charge of the organization.
The aggregate root is also called the root entity, which is not only the entity, but also the manager of the aggregate.
A collection of related objects, accessed as a whole by the outside world. The ID of the aggregate root is globally unique
relation
Refer to the entity through the aggregate root, mount the value object, and shield the internal entity logic from the outside
//聚合根
class Order {
public String id;//订单ID，全局唯一
public Address customerAddress;//配送地址
public List<Item> items;//商品信息
public Pay pay;//支付信息
public LogisticsDetail logisticsDetail;//物流信息
public Pingjia pingjia;//评价信息
}
//实体
class Item {
public Long id; //商品ID，实体主键，Order内唯一
public String name;//商品名
public float price;//价格
public int count;//数量
}
//实体
class Pay {
public Long id; //支付ID，实体主键，Pay内唯一
public String source;//支付方式
public int currency;//币种
public float total;//价格
}
//实体
class LogisticsDetail {
public Long id; //物流ID，实体主键，LogisticsDetail内唯一
public int cpCode;//物流公司
public String mailNo;//物流单
public float status;//当前状态
}
//实体
class Pingjia {
public Long id; //评价ID，实体主键，Pingjia内唯一
public String desc;//描述
public byte[] image;//图片
}
//值对象
class Address{
public String province;//省
public String city;//市
public String county;//区
}
four-color modeling method
Four-color
1. Moment-Interval Archetype (MI for short)
indicates that things happen at a certain moment or within a certain period of time, such as sales orders, customer bills, collection records, etc., and are represented by light red.
2. The PPT archetype (Part-Place-Thing Archetype, PPT for short)
refers to people or things that participate in different roles, such as commodities, accounts, stores, etc., and are represented in light green.
3. Role Archetype (ROLE for short)
abstracts a way of participation, which is undertaken by people or organizations, places or objects, such as customers, merchants, warehousing teams, financial organizations, etc., and is represented in light yellow.
4. The description archetype (Description Archetype, referred to as DESC)
belongs to the resources of the data type, the category property object of the catalog type, or can be used repeatedly by other archetypes, such as commodity categories, payment methods, method value objects, etc., use light blue express.
step
Next, we use the four-color modeling method to analyze the domain model, which is divided into four steps:
Establish a time stamp prototype: find events that need to be traced back, and find footprints based on the traced events.
Build a PPT prototype: Enrich the model and look for people/things/things around the time-scaled prototype so that it can better describe the business concept.
Establish role prototypes: further abstract roles that can participate in different processes.
Establish a description prototype: supplement some information with description objects.
example
Four-color map case of e-commerce DDD
Part of the financial domain model and the payment center model
detail
- Pink refers to the prototype of the time scale, which is the data generated by the core business, basically corresponding to the table design.
- Model attributes do not need to reflect the audit fields of the table, such as general ID, creator, modification time, soft delete identifier, etc. Model behaviors only need to design core behaviors, and the custom-CRUD method does not need to be written , the design must know the trade-offs.
- In addition to dependencies, aggregation, etc., the models in BC can use arrows to connect the core interactions between models, and the models between BCs can be connected by dotted arrows. Here I combined the DCI modeling method (D means data, C means Context, scene, I means interaction between models).
- For the unique attributes of the business, I used bold display, and I no longer have to work hard with others to analyze which dimensions these models are built with.
- For attribute changes (new/modified) that have not yet been launched, use red marks, because the domain model diagram guides our business development.
- The division of the bounded context is a very subjective boundary division. In order to allow flexible adjustment of the subsequent code, there is no need to add a bounded context to the URL design of the Controller.
fall to the ground
It is best for the architect to give the design plan and give the backbone implementation. With comparable code, developers can do functional development more accurately.