Write articles carefully and share with your heart.

Personal website: Yasinshaw.com

Public number: XY’s technical circle

Sorry in advance, I haven’t produced any new articles in the last two or three weeks. On the one hand, they are busy (lazy). On the other hand, I was thinking about what topics I could write. After all, there were not many problems I could write in daily development.

Recently, I participated in the DDD (Domain-driven design) training of the company. In addition, I am also using DDD in my current project. In the past six months, we have encountered some problems. Therefore, I plan to write some DDD articles, which can be regarded as the distillation and summary of knowledge.

Why is DDD popular?

I first heard the term DDD a few years ago. At first glance it sounds like TDD (Test Driven Development), but in reality they are completely different things. At that time, I read a blog about DDD, a large piece of professional terminology, which was confused, so I did not go further.

Although THE DDD was first proposed in 2003, it never caught on. Only in the last two years has it been known. Digging deeper into the reasons, I think there are three aspects:

  • On the one hand, DDD is designed to solve complex software problems, and most of the previous software does not have very complex logic, so it can play well without DDD.
  • Second, DDD has not had a good landing guide until the publication of “Implementing Domain-Driven Design”, which opened the door for DDD landing.
  • Third, there is no domestic team to study and preach, so there are not many people who understand it.

Later, after the fire of micro-services, we found that there is a pain point in using micro-services, that is, how to design and split micro-services. And DDD can well solve this problem, so DDD riding the wind of micro services, has become gradually known by the public.

What the hell is DDD?

DDD is the only tool in the industry today that includes requirements analysis to implementation. DDD focuses on the business, designing the code from the business point of view, and the business is the center of DDD.

DDD is divided into strategic and tactical components, which complement each other. The strategy part is to understand and tease out the business, find the core business, and better partition the system (which is why DDD can be used to guide microservice design). The tactical part is about landing on the code, using the code to clearly represent the business, and having a mature set of guidelines for how the code is layered and how it is designed.

DDD is a good solution to complex business software development, but DDD is not a “silver bullet” and DDD is not a rigid set of terms and specifications. In fact, the industry is still exploring the path of DDD practice.

Silver bullet: A convenient development technique that enables a project to be implemented more efficiently.

DDD is also not the only option, but it can be used as one of many toolboxes, after weighing the costs and benefits, you can take it out and use it with other tools to serve your business and design better software services for yourself.

So what exactly is the domain?

So the last two words of “domain-driven design” make sense, but what exactly does “domain” mean?

By analyzing the business, DDD finally constructs a “domain” and designs a full “domain model” rich in business behaviors.

In DDD, “domain” refers to a business area. For example, in an e-commerce system, there may be “goods domain”, “order domain”, “logistics domain”, “warehousing domain”, and so on. The DDD uses the strategy section to guide us in dividing the business areas by business and differentiating which areas are core and which are supporting and generic areas. We will explain this in more detail in a later article in this series.

The domain model refers to the carrier objects of the business, such as “goods”, “orders”, and so on. These objects have methods that have business meaning, such as “goods. Add to cart “method. We condense the main business logic into domain objects so that what an operation does is clear and easy to maintain.

Simply put, domains and domain models are more intuitive representations of business, putting business down to system architecture and code design.

Why do YOU need DDD?

“Even if we don’t have bugs in our software, that doesn’t mean the software model we design is good.” Using DDD can make our software design more reasonable, but not only that.

For a business complex system, using DDD has the following benefits:

  • Developers work with people familiar with the business to enhance collaboration between different roles on the team;
  • Helps business people and developers sort through complex business rules;
  • Developed software is able to accurately express business rules, design is code, code is design;

When do YOU need DDD?

There is a cost to using DDD, and your team members need to have some basic DDD knowledge, preferably some DDD experience.

To do anything, we need to measure costs and benefits, and the selection of technical solutions is no exception. DDD has a cost, but it also provides obvious benefits.

In general, DDD is suitable for “business complex” systems that “need maintenance and extension.”

First, let’s look at what business complexity means. If your system only needs to CRUD a few simple tables, you don’t need TO use DDD or even develop an application. You can probably just use a database client.

As a rule of thumb, if your system has less than 30 business operations or user stories, there is not much need to use DDD. If there are more than 30 or 40, the software becomes more complex and DDD is a good place to start.

On the other hand, even though the software is not complex now, DDD can be considered if it becomes complex in the foreseeable future as it is developed and extended. Some startups may just need a simple product to test market feedback quickly, and instead of continuing to develop and maintain it, they may want to buy it again or build it from scratch, so there’s no need to waste money on DDD.

So again, when do we need to use DDD? Complex services require long-term maintenance.

What is DDD-Lite?

As you learn about DDD, you may hear the term DDD-Lite. What is it? Is it DDD?

Ddd-lite is simply a subset of THE DDD tactical mode, which is more about the technical implementation aspect and tends to ignore the strategic part of DDD. But it can’t be called DDD because strategic patterns are very important in DDD. DDD requires both tactical and strategic patterns to be implemented, and DDD is incomplete without either part.

Using DDD alone may not fully represent the business and may result in poor domain objects. Because of the lack of DDD strategic pattern of “common language”, “bounded context” and other tools to guide assistance.

conclusion

At the heart of DDD is a single word: business. All DDD tools and implementations are business – centered and business – oriented. So if you want to implement DDD well, you must recognize the value of the business, focus on the business, and understand the business.

Stay tuned:

DDD Part 2 – Subfields and Bounded Contexts