Every once in a while, someone will jump out and criticize DDD, is it a piece of junk or a silver bullet?
When I was working in a certain company, there was a group of people who claimed that they wanted to use DDD to transform the old system and completely solve the problem of difficult to maintain the project after the core process was scaled. This diagram in a previous article is the mess before the project refactoring with DDD.
Everyone is very smart, smart to the end no one knows where to write this new requirement in the end. The architects got together to learn the spirit of DDD and produce learning reports, and after half a year, some results finally came out, some sub-projects completed the refactoring with DDD, which can be used at the end of the year to invite the credit at the reception, so we have kept up with the mainstream methodology of business development in the industry, congratulations, congratulations.
At the end of the year, a small note of anonymous questions within the department sent a straight ball to the architects: “Why is the code more difficult to understand after using DDD? The DDD pushers were so embarrassed that they had to put it off.
So do you think I am trying to criticize? Not really.
During my work in a certain division, I read all the DDD-related books on the market until I left. The theory of DDD was born relatively early, and the trend of microservices only broke out later. But microservices did not have a clear splitting guide at the beginning, people found that the bounded context in DDD seemed to correspond to the granularity of the service, and DDD became the absolute mainstream methodology for many companies to do business.
Although many technical people don’t like to hear it, there is actually no necessary connection between technical merit and business success or failure. Similarly, the right or wrong methodology and the success of the project is not necessarily related. Many large companies do business people come out to talk about their technical methodology, these people may not even know why their own projects are successful, you expect to be able to produce direct help to your scenario that may be overthought. Just as a pleasure to listen to, get a reference that may not be a problem. Really when the golden rule to implement, that hit a head bag is normal.
DDD, like other engineering methodologies, has no way to falsify. Look around, purely stacked human batteries, without DDD projects are also so many successful, everyone’s ass is still following the company’s market value, which company’s market value rose to the first in China, that their technology is awesome, this is called the market value to determine values. If a company relies on 996 success, then 996 is the magic formula for business success, do not learn you’re behind. Butt can determine the head well.
But as a reserved technical person, we should still have some understanding of the enemy when we criticize the methodology.
So this article, I will simply take you to see what those ghost terms in DDD are all about.
Tactical Design and Strategic Design
The whole DDD methodology can be divided into two big modules, tactical design, strategic design. This you as the name implies, tactical is small, strategic is big.
- Tactical design refers to the single module level design, which is basically a purely technical category of things, DDD gives some guidance methods for code naming and module design
- strategic design refers to the module splitting of large projects, which has little to do with front-line programmers, mainly how to cut the cake between bu, bu how to divide the spoils between the team
Now many school recruiting programmers may more or less encounter some OOP interview questions, such as the three characteristics of the five principles and so on, these principles are the design of some projects when you can refer to the principles, and DDD tactical design is in a single module on a variety of naming rules and design methods . However, the inventor of these principles of OOP (strictly speaking, it should be the aggregator) is uncle bob, the author of “clean code”, “clean architecture”, this white-bearded grandfather is most likely and DDD community is not a pot of urine, so “clean architecture” in this book is not mentioned in the word DDD.
How to assign the company’s business to different bu(department) to complete, this is generally the company CTO or GM to do things, how to divide the projects within the department, which groups do which things. This is the realm of strategic design . DDD claims that strategic design is also about methodology. This part is also the part that many programmers consider the most useless, and we will criticize these programmers later.
Tactical Design
Tactical design is a purely technical area, and the biggest headache is the nomenclature in it.
Anemic and congested patterns. DDD recommends that you write code in congestion mode, which is to do abstraction in the OOP way and then hang the behavior on the object instead of writing code in a purely procedural way. The advantage of the congestion pattern claimed by DDD is that most of the behavior is encapsulated inside the object, so that when we read the process code, we can see step 1, step 2, step 3 at a glance. But even if we don’t use OOP to organize behavior, we can still encapsulate and reuse different business steps. Some companies have a particularly fine service granularity, such as only 5000-10000 lines of code, the advantages of the blood-filled model claimed in DDD are not so obvious.
Value objects and entities : This is also quite outrageous, value objects are purely numeric, text types, such as.
is the value object, if we add an id to the person, so that it can represent the uniqueness of the person.
Then it is an entity.
These two concepts are just a simple classification of the objects we use every day, not very useful.
Aggregate Root: The so-called aggregate root in DDD is the entity of transaction granularity, that is, if we access the db, then we need to have an aggregate root, and if we need to operate on multiple tables in a transaction, then we need to associate a separate aggregate root to multiple tables.
The aggregation root can be composed of one entity or multiple entities, that is, you complete a db transaction with as many associated objects as there may be entities under the same aggregation root.
Hexagonal Architecture: This so-called hexagonal architecture is that all external changes other than business are abstracted into adapter interface for adaptation. If you understand a little bit of dependency inversion, then you should know how to do this abstraction. If you don’t understand it at all, then I suggest you take a look at the go-micro code. If you don’t understand it, it’s better to change your career as soon as possible.
Hexagonal architecture, which is mainly the name is too strange, in the book “clean architecture”, uncle bob also gave a diagram.
The book Evolutionary Architecture, from the staff of thoughtworks, contains a plugin architecture, which is what some people like to call a plug-in architecture.
Repo Pattern: DDD theory that the storage layer of our business projects is likely to change frequently, so the interface design of the specialized storage layer is taken out separately, called Repo Pattern, which really has nothing to say, find, getlist, save, you just have a little orm experience, what interface should be able to write out by default.
The fact is that in 2021, our storage system is basically unlikely to do the switch, even if the switch, those emerging community storage system will support MySQL protocol, infrastructure wants to invade the code, that is simply a big rebellion ah.
domain event: actually is to do upstream and downstream decoupling kafka message, we use domain event will look more foreign.
domain service: Domain service, as the name implies, you think is your own department or group of local api gateway is also possible.
In summary, if you are a programmer working in the front line of a large company for two or three years, these things above should immediately understand, nothing worth saying. If it is to go to the architect conference to show a show, you have to package a little to make yourself look less dirt, right?
Strategic design
Domain : Domain, what does your company do that you don’t even know?
Core Domain : Your company sells goods, that selling goods is the key competitive link between you and other competitors. This is the core domain, is the core business, why smart people are crowded to the core business? The soup of the core business is also better than the rice of the edge business ah.
SubDomain : Your company’s selling goods, but users can’t pay, that can’t be done, payment is the sub-domain.
Supporting Domain: Your company sells goods, but customers want to see some metrics, you must have a system that can support it, right? Maybe it’s some system that writes SQL. Supporting Domain.
Generic Domain: What do you care about your company? You have to have a system to support the employee’s employment and payroll, these are the generic domains.
In addition to the first Domain, the remaining four domains of decreasing importance, decreasing means that if the company wants to lay off employees, it is from the bottom to the top of the cut.
I said earlier that some programmers think DDD strategic design is useless, you are not even clear about their own group, engaged in the work responsibilities for the company is not important, then don’t cry when you are cut.
unified language : This is better understood, such as the word diving, when you say diving refers to this.
And when your colleague said diving he was referring to this.
Here you are talking about work, that means you must not be working in the same context, so DDD thinks that you can use a unified language for domain delineation work. After delineation, within the same context, the same term will mean the same thing when you say it. This is the Bounded Context, and it may also be a different domain.
Since the split, if we are still in the same domain, it is necessary to collaborate to complete the business process, and this collaboration of different Contexts is called Context Maps or Integration Type.
The terminology is nasty, but there are two specific ways, two microservices either through RPC communication or through MQ communication.
If the communication through RPC, that callee is generally the father of the caller, many times callee hung is to affect the caller (of course, there are fuses and other methods to avoid dying together).
If the communication through MQ, that upstream is generally the father of the downstream, because the upstream a reconfiguration, the downstream may be fried, the final consistent are bullshit, how many companies are the final consistent are relying on human repair.
This relationship between father and son is Conformist. If the father can think more about the son’s needs, that is Customer-Supplier relationship, after all, the customer is nominally still God. If there are some definitions that need to be shared across systems, such as business categories in the company, we may have to parse out the PHP file from a system to use in our own system, then we may have to use someone else’s code, which is called Shared-Kernel. Shared-Kernel
Finally, sometimes we can use something called an ACL to stop some upstream changes from intruding into our business logic.
Anti-Corruption-Layer : Anti-Corruption-Layer, that is, I want to intercept the external system changes in the docking layer, do not let other people’s shit dumped on me.
Told here, the basic concepts we have all gone through once, you have to say DDD a little useful, then I do not agree, at least after reading these books, I know where to go to make more money.