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

From the perspective of software architecture, this paper introduces the core concepts of DDD, such as hierarchical architecture, constituent elements, domain object life cycle management and so on.

The core of DDD (Domain Driven Design) is modeled for the business layer, but to ensure the relative independence of the business layer, DDD proposes the following system layering based on best practice experience:

We all know the benefits of a hierarchical structure. In Martin Fowler's famous book Patterns of Enterprise Application Architecture, there is a special chapter on Layering. The upper layer calls the lower layer one-way, and the lower layer should not know the upper layer; the lower layer can inject the logic of the upper layer by providing callback (callback, such as Observer mode, template method mode, etc.), but the lower layer still does not know the upper layer. Such as the DDD hierarchical architecture diagram above.

The basic responsibilities of each layer are as follows:

UI layer: similar to the commonly used Presentation Tier, it is responsible for interacting with the client, displaying the interface, and so on. The figure also shows that the UI layer can call any of the following layers.

Application layer: equivalent to a Facade, is a thin layer. Define the tasks to be done by the software, coordinate and organize (coordinate) to complete the jobs (tasks) required by user requests, and delegate the calls to the Domain layer. There is no business logic (rules, knowledge) in it. The functionality is somewhat similar to enterprise mode and J2EE mode Front Controller.

Domain layer: the core of business software. Responsible for expressing business concepts, business conditions and business rules. It should be noted that the technical details of the preservation (persistence) of the business state do not belong to this layer (not the business model), but are delegated to the Infrastructure layer. Within this layer, Model Driven Design should be used.

Infrastructure layer: as the name implies, this layer is responsible for providing the universal services needed by the above layers, such as sending messages (Messaging), persistence of domain objects, providing Widget for drawing UI, providing framework for communication between layers, and so on.

With the macro hierarchical framework above, you can further refine and implement a preliminary domain model using the elements of DDD.

Association indicates the connection between them. Module, which can also be called Package, is used to encapsulate a conceptually cohesive set of DDD elements to express a specific domain concept, which is equivalent to package in Java.

It is important to note the difference between Entity in DDD and Entity in common systems based on the SSH framework. The latter are often called anemic business objects (amemic domain object) because they are only related to persistence and have no business behavior to which they belong, only basic methods such as getter/setter. Accordingly, those business behaviors are moved to "Service". So there is a lot of Procedural code in Service (or ServiceImpl). So anemia business objects often coexist with procedural programming. This is actually contrary to the object-oriented concept. Writing process-oriented software in object-oriented languages (Java,C#, etc.) is a common problem for many programmers. The reason why DDD is called "OOP done right" should depend largely on the fact that it restores the "true face" of Service and domain objects.

In DDD, Service deals with the operation of cross-cutting, that is, operations that do not belong to a domain object, but belong to a certain Aspect (section), which is somewhat similar to the section in AOP. Service can exist with the Application layer in the above four layers, or the Domain layer, or the Infrastructure layer, and the granularity should be neither coarse nor fine. In Adam Bien's Real-World Java EE Patterns-Rethinking best practices, he thinks that Domain-Driven and Service-Oriented are contradictory: "Domain-driven design and service-oriented design are opposite approaches". On the other hand, because Service handles the operation of Cross-cutting, it is often the result of refactoring, rather than setting up a bunch of Service to handle business in the first place. Business processing should be placed in the object to which it belongs, often in Entity or VO. This is object-oriented. The advantages of this approach will be demonstrated when dealing with complex and ever-changing business requirements.

Above is the model element Model Components, and the following will take a look at the lifecycle elements Life Cycle Components: aggregation Aggregates, factory Factory, and warehouse Repository.

Aggregate Aggregate is a unit of data change, which is composed of a group of Entities,VO and so on. Aggregation has roots and boundaries. The aggregation can only be accessed through the aggregation root, and can only hold the reference of the aggregation root, not the reference of other members. Encapsulating data changes with aggregation can ensure that complex business rules such as data consistency constraints and invariants are well managed.

The factory Factory is used to encapsulate the creation details of the aggregation. Note that the factory here is conceptual, and the implementation can be factory method pattern, Builder pattern, and so on. It is generally believed that factories are used to create complex objects. Simple objects can be directly new.

The repository Repository encapsulates the storage and retrieval of objects (reminiscent of Spring's XXRepository). Delegate the creation of the object to the factory. Transaction control should be handed over to the client that invokes Repository.

Other concepts such as Bounded Context are related to integration and will not be introduced for the time being.

The above review once again the important concept of DDD. Hope to give the reader a basic impression. It may be easy for DDD to understand (as long as you have some experience with design patterns and enterprise architecture), but it is difficult to practice and requires constant exploration. But an early understanding of the object-oriented design ideas embodied in DDD is always good for improving your code quality and architecture quality.

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.