DDD--Domain driven design--6-step approach to poetry

I remember reading Evans's "Domain driven design – the core of software complexity" many years ago, when DDD was seldom known, let alone practiced, and this book also slept in my bookcase for many years. And recently found that not only the traditional heavy business software companies, even many internet companies are pushing DDD.

Then, in different places to listen to some of the DDD share, also read some DDD blog, but overall down, there is always a "new bottle of old wine" suspicion.

The reason: Software methodology, as of today, predecessors have summed up too many of us: object-oriented, solid principles, layered architecture, SOA, microservices, Business modeling, analysis mode, design patterns, UML, 4-color modeling, RUP 4+1, agile Development, Cap theory ...

DDD, in fact, is a methodology that draws on the strengths of the Hundred. In DDD books, you'll see things like Business analytics, technical architecture, design patterns, and so on at different levels. Therefore, the understanding of DDD requires deep theoretical and practical foundation, so that you may be a variety of methodologies "melted miscellaneous" together to form a complete system.

In this paper, we try to string up a serial methodology of software development through DDD, and finally let you have a systematic understanding of DDD, rather than the various details of DDD.

Interested friends can pay attention to the public number "the way of architecture and technique", get the latest articles.
or scan the following QR code:
What kind of software is suitable for "domain-driven"

When it comes to software development, here are some common routines:
(1) Small workshop type: pure demand-driven, or function-driven, to a function to do a, constantly tired code, the system is becoming more and more bloated, to a certain extent really can not stand, reconstruct a, and then continue, so repeatedly ...
(2) Large-scale assembly line factory: Strict software process, requirement analysis, business modeling, architecture design, detailed design, project management, test case writing. More people, more links, more documents.
(3) Technical control: To do the bottom, middleware, distributed storage, RPC framework, the main focus is on the technical level, multi-threading, operating system, data structure, algorithm.
(4) "Daniel" drive: There is a "Daniel" in the company to make a framework, or the use of an open-source framework, and then other people receive the demand, and constantly fill in the business code.
(5) Data-driven: all data in a DB or central storage, all work to the data "adding and deleting" as the center.

The above classification method, is not a complete "orthogonal decomposition", a lot of time to do development, is at the same time melted and several routines.

So what's the right kind of ddd? Or, should you consider learning to absorb DDD for your current development approach?

In the preface to domain-driven design, it is clear that to use DDD, there is a premise: "Your focus is on domain and domain logic." "Field" is the most important part of you.

In other words, if you do the software, the domain is not the most important part. For example, to do the underlying system, your most important part is storage, either to solve distributed consistency, or to solve high concurrency problems. Then maybe you don't have to do ddd.

But don't get bogged down in a myth: the "heavy technology" system doesn't need DDD. A "heavy technology" system, which may also be a very heavy-business system, can also be of great value to DDD. "The field" is complicated enough.

If your field is relatively simple, the database crud is done, and that doesn't require DDD. But the reality is that the simple and complex dividing line is not so clear. Maybe a software you just took over, found quite simple, but the more you do find the more pits, the more complex it is to make discoveries.

In addition, even in the same field, different people's view is not the same, some people will think it is quite simple, some people will think it is very complex, this is a very empirical judgment.

In this regard, "Implementing Domain Driven Design" starts with a scoring card that lets you measure whether your domain logic is complex enough to use DDD. Personally think this scorecard is a very good reference, let you have a "what is complex" have an intuitive understanding. DDD Core point 1: Unified language, analysis and design no more 2 skins

In the traditional method of software development, "analysis" and "design" are often separated. "Analysis", no matter how the technology is implemented, focused on business analysis, business modeling, modeling staff, usually not programmers, but domain experts, "design", according to business modeling results, do architecture design, detailed design, and then coding implementation.

One of the frequently encountered problems with this approach is that domain experts, architects, and programmers are not communicating on the same "thing". Domain experts engage in business models, to the design, that the business model is difficult to implement, will abandon some of the business model, and so on, after the architectural design, detailed design, the business model may be "on the shelf".

To this end, DDD invented a word: Ubiquitous Language, which allows domain experts, architects, programmers to communicate in 1 languages to avoid the "irrelevant" problem. So what are the words that this UL language contains?

Clearance Context/Sub-domain;
Entity/value object/Domain service/domain event;
Aggregate root/factory/warehouse; DDD Core point 2: Suck the director of the Hundred, for business use

As I said before, DDD is a methodology that needs to be understood, because it blends all levels of software methodology. To understand DDD, first of all, the following list of these things digestion and absorption. Schema Mode

tiering, Hexagon, SOA, CQRS, Event Sourcing analysis Mode

Refer to Martin Flower's "Analysis mode", which summarizes some common business model analysis method Design Patterns .

such as "factory", formerly said "Factory mode", mainly from the technical point of view. In DDD, it applies the idea of "factory" to the business analysis.
Of course, he also said in the book, not all "design patterns" can be applied to the business level, which can be used, which can not be used, there is no standard answer. But the idea of applying the technology model to the business level is well worth learning. the core points of DDD 3:ddd not pay attention to anything.

DDD focuses on "the field", but in the actual software development, in addition to the "field", there are some things that may also be important to us.

For example, in the book "Software Architecture Design", a 5 view of the architecture mentioned, the physical architecture/operational architecture is also critical in developing large distributed systems.

While doing business analysis with DDD, we also need to consider these issues from a technical perspective. How to realize the method of ddd–6 step into poetry

After having a grasp of DDD from a macro level, the next step is to go into the implementation process and explain how to implement DDD in one step.

Of course, the following method is only a personal point of view, everyone can according to their own practice to form their own routines. 1th Step: Digest Knowledge, comb the domain concept/process

After the demand analysis is over, we know what the system is going to do. The next step is to enter the 1th link in ddd: All the "professional nouns" and "business processes" in the carding field.

This link, the test is not "technology", but your business sense, your deep thinking ability, said the big must, including your "EQ", your communication skills, expression ability.

At this stage, you may need to communicate with many people, product managers, operators, domain experts, customers, etc. For the same "noun", different people may give you different answers, you need to refine each "noun" behind the essence.

In addition to "terminology", you need to be clear about core business processes. Each process, the participants are divided into several steps, each step has what business rules. 2nd step: Dividing sub-domains

The 1th step is almost done, just go to step 2nd. It is to be explained that there is a iterative process that does not require a 1th step to think about 100% and then move on to step 2nd.

The so-called sub-domain, is that you do not need to build a unified "big model" for the whole system, all the concepts are covered inside, this will be a big challenge to the capacity of the brain. You can according to the principle of high cohesion, low coupling, divides the domain into several subdomains, each subdomain has its own clear boundary, divide and conquer.

After partitioning, you can go back and optimize the 1th step, further refining the concept within each subdomain. 3rd Step: Find "aggregate root" in each subdomain

Subdomain has, now each sub-domain has a bunch of "concept", flat roll, equal treatment of each "concept", too trivial.
Next, in this pile of "concept" inside, find a few "boss" out, that is, the aggregation root. Each eldest brother takes a few younger brothers. 4th Step: Introducing "Domain Services" between aggregation roots

Inside each subdomain, there are a few bosses. Between the eldest brother and eldest brother, how to cooperate with each other.

For example, there is a business process, need a number of bosses, each boss with the team to do a part of the matter. You can have a boss in charge of coordination, you can also be engaged in a "coordinator", by its unified coordination of multiple bosses.

This "coordinator" is the domain service. 5th step: "Domain Events" are introduced between the Domain Services/subdomain

With "Domain Services", "Domain Services" and "Domain Services" can be introduced into the "domain event", a process is done, send an event out, another received the event, the next process to start;

Similarly, each "subdomain", at the implementation level, corresponds to an SOA service. They can also be strung together using "domain Events". 6th step: Architecture re-design

After the first 5 steps have been done, we are basically at the implementation level and how many SOA services have been established. The number of aggregate roots within each service. How many areas of service. The number of "domain events" in the service house.

But this design, too biased "business", has not considered some of the "technical challenges" to solve, such as the number of services/multiple db, after the efficiency of the query. such as the incident, how to ensure that the event is not lost weight.

That's the next thing to say. CQRS and distributed transactions: CQRS

CQRS full name is command Query Responsibility separation, that is, read and write separation.

After the demolition, not the slow query, that can achieve read and write separation, such as all the DB data to write, all into the search engine, all the query in the search engine to solve, the domain model is only responsible for writing to ask
Problem.

No search engine, with DB is the same idea. In addition to make a DB or table, the query data, in advance in this join good, check the time will not have scattered data assembled together, this is "rewriting the light reading" idea. I have already discussed this issue in 1 other blogs, "distributed architecture – Thought and theory – a summary of basic ideas". Distributed Transactions

The message does not lose weight is a key to solve the distributed transaction, on the issue of distributed transactions, I in another blog "distributed Message Queuing rocketmq– transaction messages – Best practices for solving distributed transactions" is discussed in detail, here is no longer detailed.

Below is the image of the figure to show the final results of the above 6 steps: The Entity/value object is managed by the aggregation root, the aggregation root is strung into Domain Services, Domain Services are used for domain event communication, Domain Services constitute subdomains, and domain event communication is used between subdomains.

finally

This article does not go into detail about DDD, but wants to give you a big picture of DDD and how to look at DDD. What DDD can do and can't do. Know about DDD and the various software methodologies of the traditional, there is a kind of source.

about the various terminology in DDD, the various details, the opportunity one by one to tell behind.