In 2019, I participated in the “Domain Driven Design Summit 2019” and saw the practice sharing based on DDD in domestic, foreign and different industries.
One of the characteristics of adult hot learning is to think about what I have received with my own experience. Looking back on my exposure to DDD for some time, I applied my experience and thinking to the project, which really replaced the improvement BROUGHT by DDD.
Instead of focusing on theories, this video will look at some of the technical aspects (the granularity of non-concrete code) that make my development more efficient.
- Hyperemia model instead of anemia model
- Domain + DomainService + ApplicationService
- Basic service layer
- Be consistent with the business
- A unified language
Replace anemic model with hyperemic model
The advantage of the congestion model is that I feel the benefit first.
In many previous projects, the three-tier project architecture design was adopted, which seemed fine in the short term, but as the project progressed, the Service layer became more and more bloated, and other constraints had to be added to make the project structure clear. Yes, encountering problems, analyzing problems and solving problems. However, the project is a team project, so sometimes it is easy for individuals to adhere to the constraints, but it is difficult for the team to be the most constrained, so the three-tier architecture did cause some problems in the original work.
Yes, as mentioned above, in simple scenarios, the anaemia model makes sense. But as the business gets richer, it becomes more difficult to communicate business intent through code.
After getting in touch with DDD, the domain model used the congestion model in the project development. A domain object contains both properties and behaviors, which can ensure the flexible expansion of business entities as the core. The adoption of the congestion model avoids the process orientation becoming object oriented programming. Business logic can be aggregated on domain objects where it is not easy to find duplication scattered across multiple services.
Yes, considering a single model, the sensory anemia model will be clear, but just the feeling. After practice, it will be found that the congestion model can more directly obtain the desired information related to the business after the general content sequence of the domain object of the congestion model.
02 Domain + DomainService + ApplicationService
It is not enough when the domain object has a congestion model. Because it is not appropriate to place all the code on the domain object, two other parts are needed: DomainService and ApplicationService. They each bear part of the responsibility.
ApplicationService accepts raw data or commands, which are responsible for scheduling domain practices. But it does not contain task business logic, keeping the implementation details in a black box.
DomainService is not required, but when some business logic is not appropriate for the Domain, it can be placed in the DomainService. This allows Domian to keep its logic relatively clear without the logic leaking up into ApplicationService.
03 Basic Service Layer
Those that are less business related, but more technology related, fall under the basic services layer. Such as:
- Utility classes that have no business
- The project Configuration
- A persistent Repository
- Feign that communicates with other services
- Coating the ACL
The most obvious feeling with the underlying services layer is the clarity of the project, which has two parts, the business part and the non-business part. The underlying services layer is the non-business part.
As a simple example, when doing package management, the project initially has a package at the top level: Resources, service, utils, config, Domain, repository, feign, etc. As the project changes, a new exception package will be added. What we see through the top layer is more of a technical description of the package.
With the adoption of the basic services layer, you can then move the technical parts that are not related to the business into the infrastructure, such as the exception package above. If the technical exceptions described in the package are directly placed in the infrastructure, if the business meaning is expressed through the exception, It can be placed in another appropriate package.
04 Consistent with the service
Consistent with the business, here refers to the behaviors of a class, whether the Controller, ApplicationService, DomainService, Doamin are, by the name of the class, method name, can know what this is in the processing business. Being able to identify business by method at first is not complicated, but being able to consistently express business by class name and method name is difficult.
In the original three-tier project structure, it wasn’t easy to go back and look at the project after a while and find the complete business rules in the code that you wanted to understand. The reason is that the Service is bloated, but in the DDD project structure, we can find the information we get relatively easily. In this regard, I feel the efficiency of reading code has improved.
05 Unified Language
The final step is to unify the language. Not everyone participates in Event Storming, but by doing so, the team can communicate unambiguously around the domain model as the project progresses.
The unified language is an ongoing process, and as the business changes, the domain model also needs to be synchronized to the new version.
Based on a unified language, we know exactly what needs to be implemented to meet business requirements, and we also know how the domain model will change. As the domain model grew larger over the course of the project, we still knew where the thread was. To be able to respond quickly to this change.
Thinking that there is no translation in communication, so communication will not become dull.
Reference: ThoughtWorks Insights into Domain-Driven Design