The way of realization of domain driven design

In the 2004, when Eric Evans's "domain-driven design-the approach of software core complexity" (hereafter referred to as "domain-driven Design") was published, I was in high school, and it was 8 years since I was in touch with domain-driven design (DDD). At that time, I was planning to go further on the software development, with my colleagues introduced, I began to contact DDD.

I think most experienced programmers should have heard of DDD and tried to apply it to their own projects. I wonder if you've ever been in a situation where you created a resource pool (Repository), but after a while it became more and more like the traditional DAO, did you begin to reflect on how it was done? Or do you create an aggregation and then find that the aggregation is so large, and why does it refer to so many objects, is that what I did wrong?

In fact, you are not alone, I believe most of my colleagues have encountered similar problems. Not long ago, a colleague of mine showed me the "domain-driven design" he had bought in 2007, which he had already Wei, and he told me that after reading it several times, he still didn't know how to put ddd into practice. Eric's book is good, admittedly, but we programmers always want to see practical examples that will actually make it possible for us to use DDD to guide our daily development.

So, nearly 10 years after the publication of Eric's book, we have Vaughn Vernon's "Implementation of domain-driven design," as the translator of the book, I was fortunate enough to read through the book, benefited from the conclusion that good software should be ddd.

Just as in the field of microelectronics, with the Intellectual Property Rights (intellectual), DDD concentrates the core business functions of a software system in a core domain, which includes the concepts of entity, value object, domain service, resource pool and aggregation. On this basis, DDD presents a complete set of infrastructure to support such a core area. At this time, DDD is no longer "object-oriented advanced" so simple, but evolved into a system engineering.

The so-called domain, namely is an organization's business development Way, the business value is embodied in it. For a long time, we programmers are good technical thinkers and we are always good at solving project problems from a technical perspective. However, whether a software system is truly usable is reflected by the business value it provides. So instead of drilling into the technology that never learns, why not focus our attention on the business value that the software system provides, which is what DDD is trying to solve.

In DDD, code is the design itself, and you no longer need the red tape and the design documents that will never be updated in real time. The coder and the domain expert no longer need a translator to understand what the other person is saying.

DDD is divided into strategic design and tactical design. Strategic design mainly from the top "overlooking" Our software systems, to help us to accurately divide the domain and deal with the relationship between the various fields, and tactical design from the level of technology implementation to teach us how to specifically implement DDD.

Strategic design of DDD

It should be pointed out that DDD is by no means a simple set of technical tools, but many of the programmers I see do think so, and have the idea to use DDD. Being overly wedded to technical implementation will lead to ddd-lite. In simple terms, Ddd-lite will lead to inferior domain objects because we overlook the benefits of DDD strategy modeling.

The strategic design of DDD mainly includes the concepts of domain/subdomain, common language, bounding context and architecture style.

Domains and subdomains (domain/subdomain)

Since it is a domain-driven design, our main focus should naturally be on how to design the domain model and the division of the domain model.

The field is not a very advanced concept, for example, an insurance company's domain includes the concept of insurance policy, claims and reinsurance; The field of an electronic business site contains the concepts of product listings, orders, invoices, inventory, and logistics. Here, I mainly talk about the division of the domain, which is to divide a large domain into several subdomains.

In daily development, we usually split a large software system into several subsystems. This

The partitioning may be based on architectural considerations, or it may be based on infrastructure. But in DDD, our division of the system is based on the domain, which is based on the business.

So the question is: first, which of the concepts should be modeled in which subsystems? We may find that a domain conceptual modeling is possible in subsystem a, and modeling seems reasonable in subsystem B. The second question is, how should each subsystem be integrated? One might say that it's not as simple as a client invoking a server. The problem is that the integration between the two systems involves the translation between the infrastructure and the concepts of the different domains between the two systems, with little attention being paid to the pollution of our carefully created domain model.

How to solve? The answer is: the bounding context and context mapping diagram.

Bounding contexts (bounded context)

In a domain/subdomain, we create a conceptual domain boundary in which any domain object represents only the exact meaning that is specific to that boundary. This boundary is called the bounding context. The bounding context and domain have a one-to-one relationship.

For example, it is also a book, in the publishing phase and the sale phase of the concept is different, the publication phase of our main focus on the publication date, word number, publishing house and printing factory concepts, and in the sale stage we are mainly concerned about the concept of price, logistics and invoices. What should we do, put all of these concepts in a single book object? This is not a ddd approach, and the DDD bounded context separates these two different concepts.

Physically, a bounding context can ultimately be a DLL (. NET) file or a jar (Java) file, or even all of the objects in a namespace (such as Java package). However, the technology itself should not be used to divide the bounding context.

By centralizing all the concepts in a bounding context, including nouns, verbs, and adjectives, we create a common language for the bounding context. A common language is the language used by all members of a team to communicate, and business analysts, coders, and testers should communicate directly through the common language.

Integration between the various subdomains mentioned above is also an integration problem between the bounding context. In integration, we are primarily concerned with the relationship between the domain model and the integration approach. For example, you need to integrate with a rest resource, you need to provide the infrastructure (like the resttemplate in spring), but these facilities are not part of your core domain model, what should you do? The answer is the anticorrosion layer, which is responsible for dealing with external service providers, and is also responsible for translating external concepts into concepts that can be understood in their core areas. Of course, the anti-corrosion layer is only one of the many ways of integration between the context, in addition to the sharing of the core, open host services, and other details, please refer to the "Implementation of domain-driven design," the original book. The integration relationship between the bounding context can also be understood as the mapping relationship between the domain concepts in different contexts, and therefore the integration between the bounding contexts is also called the context mapping diagram.