A highly recommended article that explains the DDD series in detail (
Yin Hao explained the first lecture of DDD series-Domain Primitive
Yin Hao Explains the Second Lecture of DDD Series-Application Architecture
Yin Hao explained the third lecture of DDD series-Repository mode
)
Own better article: what is DDD, what is cqrs
Domain design = domain model (hibernate is good at, but too heavy, see repository)
+ Domain entity (hyperemia model)
+ repository (hibernate's associated list shields the concept of repository, allowing programmers to easily filter in memory, causing performance problems. Why not use hibernate. In addition, hibernate cannot solve the problem of foreign keys being hsf, distributed.)
+ Event flow (that is, the current distributed weak dependency mode)
+ In-memory plug-in flow (a process involves different domain classes + process context, before after interface, see attached figure.)
+ Distributed plug-in type (a domain class in a process is processed by different businesses, bz context + current crd DO, business verification, that is, middle station, middle station needs levelDb + online column storage to fully reflect the value, status It is nothing more than expressing n kinds of attribute values, which is convenient for subsequent query. crud. The middle station must have the ability to automatically generate an interface, not a document hashmap, to avoid internal logic refactoring and cause the middle station plug-in to fail. How to decouple the code is a problem, and it must be done specifically A layer of internal context and external context conversion logic, annotations.)
Code maintainability-
"Authorization isolation" is not as good as "domain field isolation", each congestion model is naturally isolated. Your code for processing a certain field will never be placed in the manager of another field.
in principle:
1. Your own EO does not quote others. Each field can only exist in one EO to avoid encapsulation confusion.
2. Combination is greater than inheritance (more flexible, easier to centralize, split to other systems)
Use the responsibility chain tool manager as shown in Figure 1
Because of principle 1, if the logic of other EO needs to use the fields in other EO, it must be passed in through formal parameters. In theory, it can only be one-way dependent. In addition, it must be passed through EO. If there is only id, get it from dao through manger And assemble.
3. Reemphasize that other EOs cannot hold other EOs, or other EO fields. They can also not directly obtain data from dao through methods. That is, they cannot have
ApplicationContextUtils类.Reason: If it is in a different jvm, the method parameters are propagated through id. In the same jvm, it is best to propagate through EO, in this case, you can generate less Eo and reduce garbage collection.
4. After doing this, the manager of complex queries will be more complicated. Other business managers are very thin. It sinks into the domain entity (EO).
5. The returned bean corresponds to the domain entity 11, and has some foreign key ids. These attributes can be assigned or not assigned according to different exposed interfaces? It is best to write a new bean separately.
Assign values and bytecodes on demand through mapstruct. This way the caller will not be misled.
See qq email, if the picture is missing
figure 1:
figure 2
Two remaining issues
1. But there is still a problem with the congestion model. The outside can get this domain class, get its attributes, and perform logical processing outside the domain, and the code is messed up. This is normal, because the user system importantly reveals its attributes to the outside , The external logic is encapsulated according to the attributes of the user. It is impossible to sink all of them into the user class. So at this time there will be a new domain class. Add a prefix to the user, or a new domain term. For example, people become Father. It is possible to use inheritance, and it is also possible to use combination. Inheritance is recommended.
The key is to convert Param to Entity and then to DO
2. Under the same system, there are many businesses, and the same field attributes are processed, and methods are added to the user field. More and more, this time you need to sort out and separate the business. The most convenient way is to add a business prefix , Of course, through the same name but through a different package. But the writeability of subsequent code will be poor.
3. Combination or inheritance? Inheritance is a middle-stage gameplay, plug-in callbacks, middle-stage contains extended storage, and there is only one process assembly exposed interface. Each inherited class can implement its own callback. In
combination, middle-stage provides basic capabilities without process assembly Combination layer encapsulation. At the beginning, the inheritance is simple and fast, and the interface classes are less organized. After the inheritance is exploded, the original method must be extracted out of the interface. This will ensure that the original code changes to the minimum. After the combination, the original The abstract becomes a call implemented by the interface.
* Domain entities cannot operate storage layers such as databases or hsf layers, and require service to assemble.
* Domain entities and tables (the difference between storage) are domain entities that can be inherited, and storage can be generalized storage, both in json, document type, etc.
* It is not possible to automate architecture cutting through existing code. It is a better way to divide modules by adding new dependencies to increase the cognitive cost of cohesion and dependency, and to ensure that the dependent modules of a module are the most simplified. Therefore, opening needs to be separate Into a module, because it is necessary to understand the open system. According to the process + entity to cut. Why Didi Enterprise Taxi is a specialized system because of the increase of enterprise entities. It requires specialized departments and systems to support. This division helps productive forces.
3. How to combine with spring singleton dao, hsf facade?
Static acquisition is achieved through spring's ContextAware. There will be a container closure problem. So the flow must be interrupted before the container is closed.
4. What is the relationship between interface and inheritance?
Process pyramid, logical process orchestration through the interface (the interface has no formal parameters , the parameters are converted into domain attributes, the parameters of different domain classes will change. The essence of the domain class is to encapsulate the attribute fields ). The domain entity must implement the interface, if the entity inherits, then the new Adding domain entities will be simpler, but there will be a problem of overloading (similar to the billing method of each advertising type in advertisements, overloading, the solution is to introduce billing interfaces. Different advertising types rely on different billing interfaces.)
5. The introduction of the chain of responsibility (before, after aspect) carries out the process plug-in transformation, the core remains unchanged, and the new business is introduced through the bypass system or the plug-in system. Process orchestration is orchestrated through the end. Each capability provides extension points. Similar to a star ring.
If there is a term in a field, it is relatively simple.
For example: The assembly class that combines the wheels and the frame can be named a car, or it can be inherited and become a car, suv.
In this way, the dependence of the entire entity, the inheritance system is established. Wheels can be inherited into many subclasses, and cars can also be inherited into many subclasses. Many functions of suv cars may be combined according to the inherited components of each wheel/bearing. Use The function of is no longer the function (method) of ordinary bearings.
For example, the domain entity naming for conference room reservations.
If an entity cannot give specific terms in the field, it can only define its name based on its attributes.
E.g
There is a list of meeting rooms and reservations below meeting room reservations.
Originally tangled for a long time, both are called reservations, how to distinguish?
One way is to add an "assembly" vocabulary to the booking above. Call it RoomBookAssembleVo;
Another way is to book an item, you can add important time information.
Roombook {
Room;
List<BookTimeVo>
}