Ordinary DDD first play: eighteen-year-old DDD

DDD, a name that seems too familiar to be detailed. This year, he turns 18.

At the end of 2017, I participated as a volunteer in the first China Dome-Driven Design Summit held by my old employer in Beijing, where many domestic celebrities gathered to exchange their practices and insights on DDD, as well as some foreign guests. A little over a month ago, the 2020 Summit was also held online as scheduled. You see, years have passed, and interest in DDD is still high, as is DDD’s place in today’s software architecture.

As an idea of software architecture, its birth and popularity must have some rationality and inevitability. In other words, DDD is so popular because it sees problems in software development and proposes solutions to them. For software practitioners, it seems impossible to ignore its existence.

However, when we are ready to approach DDD to understand it, but it seems not clear what it looks like, such as seeing flowers in a fog, eventually separated by a layer. See others to play, but not under his hand, a cavity blood but depression and stop, you say not angry! Does DDD also come with hazy beauty?

Of course not. If a popular thing baffles most people, either it is really complicated, or someone wants you to think it is.

Fortunately, DDD itself is not complicated, and you have to trust that it can be viewed from afar as well as “dirty”. It’s not that it’s inscrutable to many people, it’s something else.

DDD’s indissoluble relationship with microservices

Back in 2003, Eric published his famous Domain-Driven Design book, which took four years. In other words, Eric has been thinking about DDD since 1999, almost twenty-two years ago. More than 20 years may not be enough time in other fields, but it is enough time in software and the Internet to complete one technological leap after another. It is hard to imagine a software architecture idea that has not only survived more than two decades, but is still young again.

For that, DDD has microservices to thank. In recent years, due to the rapid development of the Internet industry, the application system has become increasingly complex, and the idea of micro-services has emerged. Microservices advocate the divide-and-rule of business units and the autonomy of each module, thus reducing the complexity of the system. As it happens, this is exactly the same context-limiting idea that DDD proposed in the strategic design section. If you read Eric’s book, you might even have the illusion that microservices seem to have evolved from DDD. With DDD as a guide for microservice design, you’ll find that there’s almost no obvious violation. Because of this, DDD has been revitalized by the popularity of microservices, which is the value of DDD “strategic design” and the most important value of DDD in the current environment.

What is the kernel of DDD?

To understand this, you have to ignore the industry’s interpretation of DDD and read the original. The length of the book is long enough to scare most readers off, and it’s true that there are many so-called DDD fans who haven’t read the whole book but offer misleading interpretations. You don’t have to read from the first line to the last. Eric has already pointed out the key chapters in the preface.

To understand the DDD kernel, you must understand its location and its essentials. When Eric wrote DDD, he gave it a subtitle:

“Dzj00 Complexity in the Heart of Software- Handling of Software core Complexity”.

This sentence is the positioning of DDD and the author’s idea. The key to understand this sentence is the “core” and “complex” two words, the understanding of DDD design ideas and practice, should take into account the core complexity. In other words, DDD is not a silver bullet to solve every problem; it has a clear application scenario. Once you understand this, you should also realize that DDD is just a hammer in the architecture toolbox, and when that hammer is used depends on the situation. If your problem is complex enough, DDD may be your first choice. Otherwise, there may be a better alternative to go out and turn right.

Since DDD is positioned to address the core complexity of software development, how does it do it? To put it bluntly, the following points are the following:

• Focus on business domain and solve complex domain problems through modeling;
• Clearing communication barriers through common language;
• Embody domain models and domain logic through code;
• Improve the model through continuous evolution;
• Delimit the molecular domain by context;

Translated into plain English, it would look like this:

• In software complexity, don’t just worry about technical complexity; the complexity brought by domain logic is more important and persistent;
• Whether it is development, or product or operation, please unify the caliber and rhetoric;
• This universal language is not just talk, you’re going to model the domain into code;
• To stay close to the business, embrace change, constantly adjust and optimize the domain model;
• A big mud ball should not be allowed. It should be divided and ruled by reasonably delimiting molecular domain and boundary.

You see, the essence of DDD is nothing more than that. Is it hard to understand? It’s not about technical practice, it’s not about language choice, and you might even feel like you’ve mastered DDD, isn’t it a bit of a trance? The truth is, Eric didn’t invent DDD so much as he came up with a good name. After all, the discussion behind DDD about modeling and object orientation was very popular in those days, and all kinds of approaches blossomed. Domain-based modeling was not invented by Eric either, and the graphic comparison of data-centric and domain-driven design patterns cited below is from Ma’s book, which was published in 2002, a year before DDD, and is still around today. But I have to say that Eric’s name is very good and refined some of the concepts better. This is similar to the agile Manifesto that emerged around the same time, and the 1990s were also full of software approaches such as Extreme programming, crystal methods, DSDM, etc. These software approaches look like a thousand flowers, but they all have something in common. As a result, some old experts came up with an “Agile Manifesto” combining hundreds of theories while skiing.

DDD is similar to Agile not only in concept but also in practice. They are all open software development ideas, and there is no fixed gameplay itself, providing practitioners with rich space for imagination and communication. You can simply think of DDD as providing some kind of interface specification, but how you implement it is up to you to implement its essence and principles. As with Agile, so with DDD. Crooked mouth, the reason for the agile later appeared some fixed play, one is because the method is helpful to land, two is because the package is easy to sell money.

On the practical side, many people may still think agile is the new wave of ideas and not know much about it. Over the past two decades, agile practices have become a pervasive part of today’s software development process, but you may not realize it. For example, the Efficiency department of Alibaba, which brings together many of the industry’s agile experts who know agile well, has built Agile into the development process, you may not know it, but you are actually involved. The same is true of DDD. With the development of DDD over the past 20 years, many of the essence of DDD has been unknowingly implemented, such as the bounded context behind microservices. To some extent, they come not from DDD, but from the environment and trends.

What are the benefits of practicing DDD?

When talking about the benefits of DDD, most people probably use the following diagram (from Ma’s Enterprise Application Architecture Patterns, 2002) :

The point of this diagram is that domain-driven design patterns are better able to withstand the test of time than data-centric design patterns. Complexity increases linearly over time, and linearity means that it is ordered and not out of control. So how does it increase linearly? Mainly through the following two ways:

• Focus on the domain through a layered architecture that separates technology from domain complexity;
• Different subdomains, such as core domain and support domain, are divided by limiting context to separate domain complexity.

The complexity control achieved by these two methods makes the system have the following benefits:

• Code structure optimization: the hierarchical code structure is clearer, easy to expand and maintain;
• Domain logic cohesion: Domain logic in one place, domain behavior is more reusable;
• In addition, well-organized code is more readable and testable.

What are the disadvantages and costs of using DDD?

There is no such thing as a free lunch with DDD. While enjoying the value of DDD, we also need to pay a high price, such as the following costs need to be paid:

• The learning curve:
  • New design ideas and principles;
  • A new model;
  • New development process;
• Time and energy:
  • Discussion with domain experts during modeling;
  • Extracting domain logic from complex information and modules;
• The value of DDD can only be realized in complex problems:
  • Do not use DDD for problems that CRUD can solve, because it will complicate the problem.
  • Don’t use DDD for purely technical applications.
• Promotion and dissemination:
  • A single thread does not make a thread. If you want to be widely recognized on your own, you may be better off contracting for requirements development.
  • You need to continue to speak, to preach, to gain organizational support, to reach consensus with partners, to protect architecture, and to continue to learn.

The experience of agile over the years is that any change that involves changing the way organizations collaborate or individuals develop, from top to bottom, is extremely resistant. Because organizational relationships are about personal interests, and development approaches involve years of habit and knowledge, they can’t be achieved overnight.

Why is DDD hard to understand?

As mentioned earlier, DDD itself is not complex. The main reason why DDD is so complex and difficult to understand is that it is an open software design idea, which can be implemented in different ways in the process of practice, and DDD itself and its surrounding solutions are constantly evolving.

For example, what are you going to do when you practice a common language in a team? If you don’t know, someone will tell you that you can use Agile software development, SCRUM, User Stories, User story maps, Inception, etc. Are you confused? The topic of how to practice “user stories” could be a whole book. The “user story” thread leads to a whole bunch of engineering methods you probably haven’t even heard of. Crazy?

For example, how does a common language get written into code? If you don’t know, someone will tell you that you need to design domain models, domain services, use CQRS, event sourcing, event storms, unit testing, and so on. So many puzzling concepts, is it muddled again? For example, CQRS is often mentioned. Does it really smell that good? It is common sense to remember that every technology has its own scenarios and limitations. And when it comes to unit testing, that stack of frameworks can drink two POTS of water.

The infinite divergence and interpretation of DDD is a big part of what makes it seem so hard to understand, and it’s also artificial. DDD has never been a fixed framework and has never been limited to JAVA or a particular language. If there is, it is probably because some people want to take the results, some people want to become famous, and some people want to profit, artificially complicated it. I don’t mean to belittle anyone here, but I used to work in consulting companies, and I often mix with software methods. I know a lot about the way things work, and it’s common for bronze consultants to pile up concepts and diverge topics. Such as “complex”, it seems that there are only two words, but you can spread to talk about what is the nature of the complex, software complexity from where and so on, can also lead to Cynefin framework, where two other words not clear things that can take out again, let others it sounds quite so, actually it’s no use, is mainly used to complete, I’ve done it myself.

So to understand DDD, be sure to look at the original book for its true colors, don’t listen to the fancy version. The chatter of this article is not worth your time.

Back to reality, to do or not to do?

There is no fixed answer to this question.

I personally think DDD should be treated with a normal mind, it is just a software architecture idea, from the problem driven, recognize its essence after doing:

• DDD is not complicated, its core is unpretentious, and you may already be practicing it;
• DDD is not a silver bullet, most simple business scenarios do not need to consider using DDD, complex business problems priority DDD;
• There is no perfect DDD practice and no infallible DDD approach;
• Focus on domain model, focus on common language, focus on object-oriented, forget the obsession with DDD, forget the constraints of the framework;
• DDD has never been a stumbling block to architectural upgrades and business expansion. It’s never been DDD that bothers us.
• At QCON in London in 2009, six years after DDD was published, Eric argued that DDD’s focus had changed from organizing business logic to discovering domain architecture. At the same time, Eric agrees that the domain model is still a good model for organizing business logic, but so are object-oriented, functional programming, CQRS, and three-tier architectures. Think of it as a decade or so later, and DDD’s focus is still changing. Can’t fine taste, taste will be crazy.

Of course, many people today seem to be looking for some sort of fixed framework as they practice DDD. Yes, applying frameworks is the least brainer and can effectively lower the threshold of DDD practice at the tactical level, but it is not the whole DDD, let alone the core of DDD. Otherwise, no frame can stop you from pouring a bowl of spaghetti into it.

In fact, for most developers, there’s no need to obsess over DDD, and basic books like Refactoring, Agile Software Development, and Clean Software Architecture are more useful.

Extensive reading and references

• Old experts talk DDD:martinfowler.com/bliki/Domai…
• Here’s what you’re looking for: github.com/heynickc/aw…
• InfoQ: www.infoq.com/domain-driv…
• www.domainlanguage.com
• www.dddcommunity.org
• 2020 China Domain-Driven Design Summit

About the author

Pay attention to the public number [technology at 8:30], timely access to the update of the article. Pass on quality technical articles, record the growth stories of ordinary people, and occasionally talk about life and ideals. 8:30 am push author quality original, 20:30 PM push industry depth of good articles.

If this article has been helpful to you, please like it, follow it, and monitor it as we go from bronze to King.