Domain Driven Architecture-Diamond Symmetrical Architecture
In domain-driven design, there is a guiding ideology for the architectural style: different bounding contexts can choose different architectural styles according to their domain model and business characteristics.
In the process of combining the traditional layered architecture with the domain-driven concept, a variety of architecture styles have emerged: hexagonal architecture, neat architecture, microservice architecture, etc. This article is based on reading and thinking about the chat related to IT artist Zhang Yi.
Preface
Rhombic Symmetric Architecture is mainly aimed at domain-level architecture. It draws on the knowledge of hexagonal architecture, layered architecture, and clean architecture, and combines the meta-model of domain-driven design, so that it can be better applied to the boundaries. In the context of architectural design.
The road to architecture evolution
Hexagonal architecture
The characteristic of the hexagonal architecture is: while satisfying the idea of a clean architecture, it pays more attention to the nature of communication between the inner and outer layers and external resources.
There is an adapter corresponding to each type of the outside world: message adapter, REST adapter, SOAP adapter, persistence adapter
The boundary between the domain and the technology is clearly shown through the different boundaries of the two hexagons inside and outside ( blue is the domain, gray is the technology )
- Port: We can regard the port as a specific protocol
- Adapter: regarded as a specific vertical communication technology, such as Servlet, REST, JPA
- Application: Use case-level business logic, reflecting a business scenario
- Domain model: system-level business logic, multiple services and aggregation constitute a use case
In the hexagonal architecture, the port is the key to decoupling: the entrance isolates external requests and technical implementation details; the exit isolates data persistence and external access devices
An example of a business with a hexagonal structure (reservation of air tickets):
- ReservationResource: The booking request is sent to the resource service defined by the RESTful contract. It serves as the entrance adapter and lies within the boundary between the application hexagon and the domain hexagon. After receiving the front-end request in JSON format, it will be sent Convert (deserialize) the request object required by the entry port ReservationAppService
- ReservationAppService: The entry port is the application service, located above the boundary of the domain hexagon. When it receives the converted request object from the entry adapter, it calls the domain service TicketReservation located within the boundary of the domain hexagon
- TicketReservation: the domain logic of ticket booking
- ReservationRepository: The exit port is the resource repository, located on the boundary of the domain hexagon, defined as an interface
- ReservationRepositoryAdapter: The logic of actually accessing the database consists of an exit adapter between the application hexagon and the domain hexagon. This implementation accesses the database and converts the request to insert the booking record sent from the port into a message that the database can receive. Perform an insert operation
Neat architecture
The neat architecture model is an inner and outer layer structure similar to the kernel mode. It has the following characteristics:
- 1 The closer to the center, the higher the level
- 2 From outside to inside: framework and driver--"interface adapter--"application-level business logic--"system-level business logic
- 3 The dependencies in the source code must point to the inner layer of concentric circles, from outside to inside
We can get a lot of memorable design ideas in the neat architecture:
- Components of different levels have different frequency of change, and the reasons for the change are also different (in line with the design idea of high cohesion and low coupling)
- The higher the level, the less dependent the internal components, and there is no dependency on the core business entity (the domain model and technology are perfectly decoupled)
- The closer the level is, the closer the relationship between the internal components and the business is. It is difficult to form a general framework for content that is exclusive to a specific field (the field creates barriers)
In this architecture, the outer circle represents the mechanism, and the inner circle represents the strategy; the mechanism is related to the specific technical implementation and is vulnerable to changes in the external environment; the strategy is related to the business and encapsulates the core domain model, which is the most difficult Affected by changes in the external environment
The hexagonal architecture only distinguishes the internal and external boundaries, and refines the roles of ports and adapters, and does not plan the relationship between the various levels and objects within the bounding context; and the clean architecture is too general, which refines the basic rules of enterprise system architecture design With the subject. Therefore, when we introduce the hexagonal architecture and clean architecture ideas into the bounded context of domain-driven design, we also need to introduce a layered architecture to give more detailed design guidance, that is, determine the relationship between layers, modules, and role stereotypes. relation.
Classic layered architecture
Layered architecture is the most widely used architecture mode. Almost every software system needs to isolate different concerns (Concern Points) through layers to deal with changes in different requirements, so that such changes can be carried out independently.
- User interface layer: Responsible for presenting information to users and interpreting user commands. Including web UI interface, mobile UI interface, third-party services, etc.
- Application layer: A very thin layer used to coordinate application activities. It does not contain business logic, and it does not retain the state of business objects. In domain design, it is actually a facade, which is generally called by the controller in the basic setting layer of other boundary contexts.
- Domain layer: This layer contains domain information and is the core of business software. The state of the business object is retained here, and the persistence of the state of the business object is delegated to the basic setting layer. It includes domain design: aggregation, value object, entity, service, resource interface, etc.
- Basic setting layer: Don't simply understand it as a physical layer, it exists as a support library for other layers. It provides communication between layers and realizes the persistence of business objects. Generally include: network communication, resource realization (database persistence realization), asynchronous message service, gateway, controller control, etc.
Rhombus symmetrical architecture
The diamond-shaped symmetrical architecture combines the ideas of a layered architecture and a hexagonal architecture.
Hierarchical mapping of hexagons
- Ingress adapter: In response to requests from clients outside the boundary, inter-process communication and message serialization and deserialization are required. These functions are related to specific communication technologies, so they are mapped to the infrastructure layer
- Entry port: Responsible for coordinating the interaction between external client requests and internal applications, which matches the coordination ability of the application layer, so it is mapped to the application layer
Application: Undertaking the domain logic of the entire bounding context, including the domain model of the current bounding context, it should be mapped to the domain layer without a doubt - Exit port: As an abstract interface, it encapsulates the access to external devices and databases. Since it will be called by the application, it should follow the neat architecture idea and should also be mapped to the domain layer.
- Export adapter: the real realization of access to external devices and databases, which is related to the specific technical realization, and is mapped to the infrastructure layer
Break through the layered architecture
The layered architecture is only a logical division of the bounded context. When coding is implemented, the logical layer may be expressed in the form of a module, but it may also be the entire bounded context as a module. Each layer is just a difference in the namespace, defined as A package within the module. Regardless of whether it is a physically separated module or a logically separated package, as long as the bounded context can maintain the clarity of the internal structure under the protection of the hexagonal boundary, the risk of architecture corrosion can be reduced.
According to the "principle of stability dependence" followed by a clean architecture, the domain layer cannot depend on the outer layer. Therefore, the egress port can only be placed at the domain layer. In fact, the same is true for domain-driven design. It defines a repository in the domain model to manage the life cycle of the aggregation. At the same time, it will also serve as an abstract exit port for accessing external databases.
Putting the resource library at the domain layer is indeed supported by arguments. After all, after erasing the implementation details of database technology, the interface method of the resource library is the management of aggregated domain model objects, including query, modification, addition, and deletion behaviors. It can also be regarded as part of the domain logic.
However, the bounded context may not be limited to accessing the database, but may also access files, networks, and message queues that also belong to external devices. In order to isolate the domain model from external devices, it is also necessary to define abstract egress ports for them. Where should these egress ports be placed? If it is still placed at the domain level, it is difficult to justify it. For example, the export port EventPublisher supports publishing event messages to the message queue. To put such an interface on the domain layer, it seems nondescript. If it is not placed at the core domain layer, it can only be placed outside the domain layer, which violates the idea of clean architecture.
Since the location of the exit port is so awkward, and it is obvious that the exit and entry are not symmetrical, we simply symmetrical the exit and entry, unify the ports and adapters, and combine them into a "gateway".
Although the above symmetrical architecture is born out of the hexagonal architecture and the domain-driven design layered architecture, it is different from the two.
The remote gateway and the local gateway defined by the symmetrical architecture northbound gateway assume the responsibilities of ports and adapters at the same time, which actually changes the style of the hexagonal architecture port-adapter; the internal and external hierarchical structure of the domain layer and the north-south gateway layer, and the southbound The separation of ports and adapters specified by gateways is further away from the layered architecture of domain-driven design.
Now that it has changed, re-abstract the architecture diagram based on ideas
The diamond-shaped symmetrical architecture is obtained, which mainly reflects the symmetrical relationship between the north-south gateways
The composition of the rhombus symmetrical architecture
The composition of the context of the diamond architecture:
- The remote gateway of the northbound gateway: inter-process communication
- Local gateway of northbound gateway: In-process communication
- The domain model of the domain layer: domain logic
- The port abstraction of the southbound gateway: the abstract borrowing interface of various resource library operations, which can be relied on by the domain layer,
- Adapter implementation of the southbound gateway: the implementation of the gateway port, the implementation of the adapter is injected into the domain layer through dependency injection at runtime
Taking the business example in the hexagon as an example, if it is changed to a diamond structure, the structure is as follows:
Introduce context mapping
Northbound gateway evolution
The northbound gateway is similar to the open host service, but has more functions, equivalent to the open host layer, including remote services and local services
- Remote service: cross-process communication; including resource (Resource) service, provider (Provider) service, controller (Controller) service and event subscriber (Event Subscriber) service
- Local service: In-process communication; corresponding to the application service of the application layer
When an external request enters from a remote service, if the domain logic of the domain layer needs to be invoked, the request to the domain layer must be initiated via the local service. At this time, the local service plays the role of the port, and the remote service can be considered as the client of the local service.
Southbound gateway evolution
The southbound gateway introduces an abstract port to isolate the internal domain model from accessing the external environment. This value is equivalent to the anti-corrosion layer in the context mapping, and it also expands the function of the anti-corrosion layer
The ports of the southbound gateway are divided into:
- Repository port: Isolate access to external databases, and the corresponding adapter provides aggregated persistence capabilities
- Client port: Isolate access to upstream bounded context or third-party services, and the corresponding adapter provides the ability to call services
- Event publisher port: Isolate access to external message queues, and the corresponding adapter provides the ability to publish event messages
Improved diamond-shaped symmetrical architecture
The diamond-shaped symmetrical architecture removes the concepts of the application layer and the infrastructure layer, and summarizes it with a unified gateway layer, and reflects requests from different directions in the north and south directions. The symmetrical structure formed in this way highlights the core role of the domain model and more clearly reflects the boundaries between business logic, technical functions and the external environment.
The resource library is regarded as the port and adapter of the anti-corrosion layer, and as the role stereotype in domain modeling, it is better integrated with the scene-driven design to enhance the stability of the domain model. After the application layer is removed, it is weakened to the local service of the open host service layer, which is equivalent to returning to the essence of the service appearance from the design level, and also helps to resolve the conceptual dispute between application services and domain services.
Code model example:
ohs is the abbreviation of open host service mode, acl is the abbreviation of anti-corrosion layer mode, pl stands for publishing language; you can also use northbound and southbound instead of ohs and acl as package names, and use messages contract Replace the package name of pl.
Reprinted address: DDD field drive strategy (6) Diamond-shaped symmetrical architecture
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。