Refer to the reference

1. How to implement business modeling (Xu Hao)

When using domain-driven design, we typically divide the system into four layers:

  1. Representation Layer: Responsible for the presentation and interaction of user information.
  2. Application Layer: It is responsible for supporting specific business or interaction processes and organizing business logic into software functions.
  3. Domain Layer: core Domain concepts, information, and rules. It should be the most stable module in the system, and it will not change with the flow of the application layer, the interface of the presentation layer, and the capabilities of the infrastructure layer.
  4. Infrastructure Layer: Common technical capabilities, such as databases, message buses, and so on.

Why stratify?

The causes and frequencies of changes in each layer are different. Changes in the lower layer will affect the upper layer, so in order to isolate changes, we want to control the propagation of changes through layers. Therefore, the lower layer components should be more stable than the upper layer components.

Infrastructure layer and domain layer who is stable

During the limited life cycle of a software system, we can assume that the domain layer should be constant. The domain layer should be the most stable.As shown in figure,The domain model’s attitude to infrastructure is very subtle:

  • Domain logic must rely on infrastructure to perform its functions;
  • The domain model must emphasize its stability in order to maintain its central place in the architecture.

And as it is supposed to be absolutely stable, it cannot rely on any non-domain logic (other than the base library). Any dependency on other logic will lead to the passing of changes, making the domain layer unstable. Because of the dependency on the base layer, the domain layer is not the most stable layer in the hierarchy; the infrastructure layer is.

How do you resolve the dependencies between the domain layer and the infrastructure layer

Infrastructure is not a layer

Because we artificially set the domain layer to be the most stable, the infrastructure layer used to implement the domain layer cannot be more stable than the domain layer. So we have only two options: either admit that the domain layer is not the most stable (i.e., the domain layer is “the implementation of the domain model on a particular technology stack”); Or don’t think of infrastructure as layers.

As an aside, IN fact, I always recommend not to overemphasize the absolute independence of the domain layer. It is easier to accept that the domain layer is not an idealized realization without constraints, but a realization constrained by specific technology stack and technology ecological environment, so that there will be less trouble and entanglement.

Capability Supplier model

Through capabilities and capability vendors, another interaction between layers emerges: the upper layer acts as a capability vendor for the next layer, participating in the business and processes of the next layer. And this participation does not entail additional dependence. The schematic is as follows:

Interface isolation rule and inverted dependency rule:

  1. Abstracting capabilities with business implications into interfaces into the domain layer.
  2. The infrastructure layer implements the business interfaces of the domain layer.
  3. The DI framework implements dependency inversion and interface isolation. In this way, the domain layer only depends on the interface of the domain layer, the infrastructure layer.

By abstracting capabilities that have business implications from technical components, we can transform the infrastructure into a provider with that capability. We can then help the domain layer achieve the kind of “perverse relationship” it desires, using the infrastructure without relying on it: we rely on the capability interfaces within the domain layer (the interface isolation principle in SOLID) rather than the implementation of the underlying design (the inverted dependency principle in SOLID).