DDD understanding of Domain Driven Design

Write it at the front ：9 Graduate school starts in January , The internship should come to an end .

Perhaps the best way to learn is to systematize what you already know .

Development should not always focus on the implementation of a single function , The maintainability and expandability of the whole system should also be considered . That being the case , But every time I write code, I don't look at it myself .

---

---

DP - Domain Primitive

Tradition POJO There is only getter、setter Method , however DP But it contains more logical structures , There may be initialization 、 check 、 Attribute processing, etc , in other words DP Not only have properties , Also has attribute related responsibilities . But how to define the boundary 、 How to grasp the intensity 、 Cohesive boundaries require a wealth of experience .
DP The three principles of ： Let the implicit concept become explicit 、 Let the implicit context be explicit 、 Encapsulate multi object behavior .1、 Let the implicit concept become explicit , Attribute behavior （ Such as get operation ） Explicit hidden attributes .2、 Let the implicit context be explicit , The implicit context is represented as a class attribute .3、 Encapsulate multi object behavior , One DP You can encapsulate the behavior of multiple objects .

Examples of refactoring are DP Instead of DTO Concrete realization

Entity

Entity classes describe the information that entities in this system should contain , Try to communicate with DP Composition brings together more checksums and implicit attributes , And common combinations Repository layer , That is to say, the definition is finished Entity After all, it is in the database Repository Floor to floor implementation .Repository Is the abstraction layer of data access .

Entity and DP The essential difference is whether there is a data state in semantics . such as User yes Entity, It's stateful .DP It's the composition Entity The type of Foundation .

What is a state ？ The conclusion is that “ Whether the object has a lifecycle ”,“ Whether the program needs to track the change event of the object ”,Eric Evans The example is the seats in the stadium , The audience bought the tickets , Each ticket corresponds to the seat number , In this scenario, the seats are stateful , yes Entity, Our program needs to pay attention to the change event of the object , For example, pay attention to the reservation status of seats , Price , Location and other attributes , Another scene , The audience can sit at will after buying tickets , At this time, the seat is stateless , Namely DP, Just pay attention to the total number of seats .

In my understanding Entity and DP It can be seen as what other architectures say Model layer , That is, the model layer , Our model for domain modeling , That is to say Entity and DP.

Repository

In the abstraction layer , We only define actions , Such as save、find etc. , Re realization Impl Implementation class . stay Impl What is in the implementation class ORM Look at the technology selection .

Domain Service

Set up Service Layers are mainly used to encapsulate multiple Entity Or cross business domain logic . Arrange according to the business description Entity and Service

ACL - Anticorrosive coating

Prevent external systems from rotting and affecting our own systems .

Mainly between the two systems model（ Model ） Or protocol conversion ,ACL Try to transform the model of the system provider into the model of the system user （ Without introducing the intermediate third-party model ）

A simple example is that of other systems RPC The returned result of the service is encapsulated as its own DP

Face to face abstract interface programming

Reduce external coupling , All facilities and services that do not belong to the current field can be considered as external dependencies , Like databases 、schema、RPC service 、ORM、 Middleware etc. , One feature is that these dependencies can be replaced , such as Mysql Replace with postgresql,schema Add several fields to the change table of . External dependencies change , It is also necessary to minimize the change of the system .

Abstract interface is essentially an intermediate protocol , The relying party and the dependent party are only responsible for this agreement , Interfaces separate software hierarchically , In this isolation , Any changes at any level will be controlled within the current range .

for instance , For example, the specific operator's RPC Service service , We can create abstractions RPC Service implements Of specific operators RPC Service service . Implementation objects are injected through dependency inversion .

unit testing

Unit testing is an easy point to ignore in development , Highly coupled test cases are multiplicative levels , The test after layered decoupling is an addition order quantity . Be sure to ensure coverage .
The common technology selection is Mockito.Ctrl+shift+T, Create a new test class , Class plus @SpringBootTest annotation . Using dependency injection we need Service, Or use @MockBean Inject （@BeforeEach Method used in Mockito.when Returns the object ）, In the implementation method Assert. Assertion .

The important point of unit testing is to write the expectations and results , And coverage

UL - Unified language

Uniform terminology , Especially in the code of strong business correlation , What do various variables mean , Will there be ambiguity , These issues need to be defined and unified , When taking over the project on the way , Especially those with strong business relevance , When looking at the project, first look at the external interface , Don't go into the code implementation right away , This part is about business , Need to consult an expert , Or ask the elder to have a chat during dinner , Continuously digest the business domain knowledge .

Model value

As the business becomes more complex , It needs to be restructured and reformed at key nodes , Introduce a good model , Otherwise, technical debt will inhibit the growth of the business , At this point, the value of the model becomes higher . The requirements for modeling are different when the business is in different periods .

Of course, if you just develop a simple page or pages , Then there is no need to invest too much , At this time, the value of the model is low , Use sewers （ "Thirty-three ） There is nothing wrong with the way it is written .

In order to build valuable models , I need to UL On the basis of , Digest knowledge , And extract knowledge from the model .

I understand that the model here can be regarded as stateful Entity And stateless DP 了 , It also needs more design architectures （ Such as php Of TP5） Generic Model layer .

Aggregate root

In a complex system , Modify an object , The state of a large number of other associated objects may be involved , Relationships in objects are a bit like graphs in data structures , With polymerization Aggregrate Describes a collection of objects that have referential relationships .

Aggregation is the encapsulation of a set of objects with reference relationships , The purpose is to shield the complex relationship between internal objects , Only the unified interface is exposed （ Root object ）, About polymerization , We need to focus on two of its properties , Root object and boundary .

The root object is Entity, need ID And status distinguish other aggregations , Within the aggregation, a series of logic is executed to keep the state of each object consistent .

To identify the root object, it is recommended to use the implementation as the interface to identify the parent class DP, It is not recommended to use String type .

BC - Bound context

The bounded context is used to subdivide the domain , So as to define the boundary of the common language .

The essence is to solve the domain partition problem of complex systems , The clearest way to divide and conquer domains is to split them into microservices , But there are boundary problems in splitting services , And it will also increase the complexity of communication .DDD Pass through BC Thinking solves the problem of dividing and governing fields

1、 Domain isolation , Such as payment and refund services , It should be divided into
2、 Model isolation , How many iterations in a field may generate multiple sets of models , Even share some logic and code , But the goal is to completely migrate from the old model to the new model , Then these models should use BC Isolate as much as possible , Where the models intersect, they are adapted by implementing a converter , In this way, it is relatively safe to modify the code in a set of models .

Model isolation in the same domain ：
1、 In different package paths
2、 In different module
3、 In different container contexts

Practical experience

Preliminary Abstract requirements , Abstract several fields from the business , Define the responsibilities of each area , And the domain is divided into sub domains and the dependencies are sorted out

Divide the field , In the system development, we should always remind ourselves of the current work. The transformation of the system is the focus of the current field , In this way, we can avoid the confusion of responsibilities among various fields .

There are communication requirements between each sub domain , Depending on the context of the bound , What relationships exist in the bounding context , These relationships are called context map. Communication with external areas should be through anti-corrosion coating

There are many terms in a field , The terms created according to the business development needs inside and outside the team need to be unified , In case of ambiguity, communication will be difficult .

For each subdomain , Design module structure organization （ According to the requirements of the company ,DDD There is no clear way to organize code modules ）, Design modeling , Yes DP,Entity, polymerization . Aggregation and aggregation roots are difficult , Need to master .

On coding , It is important to use design patterns flexibly , We should take full account of the future expansion .