IS DOMAIN DRIVEN DESIGN (DDD) RELIABLE?

On April 10, 2022

hello, hello everyone, i am zhang zhang, the author of the public name “the road to architectural improvement”.

IT SEEMS THAT IN RECENT YEARS, DDD HAS BEEN PARTICULARLY HOT, AND THERE ARE STILL MANY ANALYSIS NETWORKS ON WHETHER DDD IS SILVER BULLET OR GARBAGE.

RECENTLY, ONE OF THE CLASSMATES IN THE GROUP BECAME OBSESSED WITH DOMAIN-DRIVEN DESIGN (DDD) BECAUSE HE SPENT MONEY ON GEEKS TO LEARN DDD COURSES, AND THEN HE WAS BENT ON PUTTING IT INTO PRACTICE IN HIS WORK PROJECT AND MAKING THE THEORY LAND 😂

1. DDD HIERARCHICAL ARCHITECTURE

I BELIEVE THAT MOST DEVELOPERS WHO UNDERSTAND DDD MAINLY BELIEVE THAT THE SUPPORTIVE VIEW IS:

DDD (Domain Driven Design) is a software development approach that helps us design high-quality software models. When implemented correctly, the design we do with DDD is exactly how the software works.

the key to business system design is how to define the model of the system and the relationship between the model, which is mainly the definition of the domain model, and when we determine the model, the relationship between the models will also be clear.

Eric Evans proposes the traditional four-tier architecture model in his book Domain-Driven Design – Coping with The Core Complexity of Software.

a brief summary is as follows:

Interface layer Interface: mainly responsible for interacting &communicating with external systems, such as some dubbo services, Restful API, RMI, etc., this layer mainly includes Facade, DTO and some Assemblers;
Application layer Application: The main component contained in this layer is the service service, but it should be noted that the service of this layer is not a simple DAO layer packaging, in the domain-driven design architecture, the service layer is only a very “thin” layer, it does not implement any logic inside, but is responsible for coordinating and forwarding, delegating business actions to the lower domain layer;
Domain layer Domain😀 omain layer is the core of the domain model system, responsible for maintaining the object-oriented domain model, and almost all business logic is implemented at this layer. It mainly contains a variety of important domain components such as Entity, ValueObject, Domain Event, and Repository.
Infrastructure: It mainly supports the interfaces, applications, and domain layers. All platform-specific, framework-related implementations are provided in the infrastructure, avoiding three layers, especially the Domain layer, from being adulterated into these implementations, thus “polluting” the domain model. The most common type of facility in Infrastructure is a concrete implementation of object persistence.

2. anemia model vs congestion model

Q1: WHAT EXACTLY IS THE SO-CALLED “ANEMIA MODEL”?

Under the traditional MVC hierarchical architecture, we divide the project structure into three main layers: Controller, Service, and DAO, and all the business logic is reflected in the Service, while our entity class Entity only acts as a data container that maps to the database orm, which does not reflect the business value of the model.

Q2: WHAT ARE THE DISADVANTAGES OF THE “ANEMIA MODEL”?

We’re going to see all sorts of setter methods and all sorts of parameter validation code everywhere in our code, especially at the Service layer, but it doesn’t reflect its business value. DDD recommends that you write code in congestive mode, that is, abstract it in the way of OOP, and then hang the behavior on the object, rather than writing the code in a purely procedural way.

Q3: WHAT IS THE SO-CALLED CONGESTION?

that is, the object itself has many associated behaviors, rather than just a field mapping of a database table.

The DDD’s claimed advantage of congestion mode is that most of the behavior is encapsulated inside the object, so that when we read the flow code, we can see steps 1, 2, and 3 directly. But in fact, even if we don’t use OOP to organize behavior, we can encapsulate and reuse different business steps.

SOME COMPANIES HAVE A PARTICULARLY FINE SERVICE GRANULARITY, SUCH AS ONLY 5000-10000 LINES OF CODE, AND THE ADVANTAGES OF CONGESTION MODE CLAIMED IN DDD ARE NOT SO OBVIOUS.

third, is it convenient to guide the division of microservices?

I believe that many friends understand that “DDD can effectively guide microservice splitting”, and on this point, it is mainly using bounded context.

A bounded context is an element in DDD that divides different business boundaries, where the meaning of a business boundary is the problem domain that “solves different business problems” and the corresponding solution domain. You can think that a bounded context exists to solve some type of business problem.

so how to divide it?

IT IS MAINLY THE ABSTRACTION OF DATA AND FUNCTION. FOR EXAMPLE: TAKEAWAY, PROPERTY, ERP THESE PRODUCTS COMMON DATA MODEL, USER RESOURCES CAN BE SPLIT INTO A SERVICE, IS NOT IT? BUT THIS IS THE FIRST STEP IN THE LONG MARCH, AND IT IS DIFFICULT TO APPLY DDD IN SPECIFIC CODING PRACTICES.

Many people conclude that DDD is helpful for service segmentation, but it is very demanding on the ability of personnel.

the architectural evolution of any software is spiraling.

when there is not enough experience to solve the problem directly, or the problem is too large to be solved with experience, the only thing that can support your decision is to effectively analyze the input problem.
USING DDD TO GUIDE MICROSERVICE DIVISION CAN MAKE UP FOR THE LACK OF EXPERIENCE TO A CERTAIN EXTENT AND MAKE A REASONABLE AND WELL-FOUNDED SYSTEM ARCHITECTURE DESIGN.

fourth, let’s sum up

the focus of domain-driven development is on the domain model, and all considerations should be from a domain perspective, with a focus on the business. domain models must be able to accurately express business logic, domain models need to be continuously refined during the development process, and can guide engineers in their development work.

however, the reality is often not as we expect:

THERE ARE STILL TOO FEW BEST PRACTICES FOR DDD IN CHINA

EXCEPT FOR A FEW WELL-KNOWN LARGE MANUFACTURERS, IT IS RARE TO SEE THE IMPLEMENTATION OF DDD, AND TOO FEW BEST PRACTICES MEAN THAT THERE ARE FEWER MATERIALS WE CAN REFER TO AND THE RISK OF PROJECT FAILURE IS GREATER.

MANY NEW CONCEPTS AND TERMS HAVE EMERGED IN DDD

CONCEPTS SUCH AS AGGREGATE ROOTS, VALUE OBJECTS, HEXAGONAL SCHEMAS, CQRS (SEPARATION OF COMMAND AND QUERY RESPONSIBILITIES), EVENT-DRIVEN, AND SO ON. WHEN MANY PEOPLE SEE SO MANY CONCEPTS, THEIR HEARTS BEGIN TO RETREAT.

If you are a programmer who has worked in the front line of a large company for two or three years, the essence of these new concepts and nouns should actually be well understood. There is nothing worth saying. If it is to go out and share the show, you can learn from the packaging, don’t make yourself look so dirty, hahaha~

ROI NEEDS TO BE FURTHER DISCUSSED

DDD REQUIRES A LOT OF TIME AND EFFORT ON OUR DOMAIN MODELING, AND IT CAN LEAD TO SITUATIONS WHERE THE PAYOFF AND THE BENEFIT ARE NOT PROPORTIONAL. BECAUSE THE DIVISION OF THE BOUNDED CONTEXT IS A VERY TEST OF THE ARCHITECT’S BUSINESS LEVEL. IF THE BUSINESS MODEL IS NOT WELL IDENTIFIED, IT MAY SOON BECOME CORRUPT IN THE PROCESS OF ITERATION.

TODAY, I MAINLY TALKED TO YOU ABOUT THE MAIN CONCEPTS AND SERVICE DIVISIONS OF DDD. IN FACT, TO USE DDD IN SPECIFIC CODE, IT ALSO REQUIRES A HIGH LEVEL OF ABILITY OF DEVELOPERS, NOT ONLY TO KNOW THE THINGS ON THE EIGHT STRANDS, BUT ALSO TO HAVE HIGH REQUIREMENTS FOR CODING SKILLS.

finally, let me say that it is better to believe in books than to have no books, and practice is the only criterion for testing truth!

Thanks for reading!released: april 08, 2022reads: 580

original link: [https://xie.infoq.cn/article/00390d9067add4aa58dcb9daa]. please contact the author for article reproduction.