This is the 7th day of my participation in the August More Text Challenge

The first three chapters of DDD Introductory Summary have covered several points

  1. What is the DDD
  2. Characteristics of complex systems
  3. How does DDD deal with complex systems
  4. Modeling concepts
  5. Software development process

However, DDD materials are usually divided into two parts: strategy and tactics, so summarize the two categories

tao

Before we discuss strategy and tactics, let’s describe the tao.

DDD is a software development methodology, and any methodology must be implemented to reduce code complexity.

So what is tao?

Always thought DDD’s strategy was tao, but got it wrong

The ultimate “tao” of software development is “high cohesion, low coupling”, which is the embodiment of any valuable idea or method

How can this ultimate path be reached?

    1. DRY
    1. Separation of concerns
    • 2.1. Separation of business and technology
    • 2.2. Service and deployment separation
    • 2.3. Separation of change and invariance
    1. Narrow your dependency
    1. It depends on stability

strategic

The DDD strategy consists primarily of a unified language and a bounded context

A unified language

In the past OO development process, will go through OOA, and then OOD, complex system, no one can fully understand the system and achieve the system, the industry has a specialist, professionals do great things, this is correct

But after the division of labor, team cooperation communication is crucial, in the whole system development process, there is a main line, that is business knowledge, business knowledge in the system before landing through layers of transmission, out-of-shape deformation is often a thing, from the developer after how many times of rework is very clear

How to solve this problem? DDD introduces a unified language, which determines the meaning of business terms in advance and reduces unnecessary translation process. Cars are on the same track, books are on the same text and lines are homotopy

This also eliminates duplication between business and technology, using common business primitives for dialogue

Code is documentation, code is domain knowledge

userService.love(Jack, Rose) => Jack.love(Rose)
companyService.hire(company,employee) => Company.hire(employee)
Copy the code

Bounded context

Boundary context covers all aspects of the realization path, such as separation of concerns, each context around a concern, clean architecture to make each layer in a stable direction of dependence, reasonable division of boundaries, so that the dependency between each context is reduced

To put it bluntly, bounded context is to divide and conquer a large system

Bounded context is the core of DDD, but it is often overlooked by technical people. For pragmatic programmers, tactics are often more attractive. In fact, the concept of context permeates everything from microservices to entity classes

The purpose of introducing bounding context is not how to divide the boundary, but how to control the boundary

According to Alberto Brandolini, bounded context is a mean of safety. Safety means being in control and no surprise. Being able to control the bounded context means that your system architecture and organizational structure are under control

Obviously, the bounded context is not a module, service, component, or subsystem, as most programmers understand it, but rather your control over domain models, teamwork, and technical risk

The bounded context is the embodiment of the divide-and-conquer architecture principle. We introduced it to control software complexity. It is not a fixed design unit, not a module, a service, or a component, but rather to help us make highly cohesive and low-coupling designs. As long as this design is followed, a bounded context can be a module, service, or component. Therefore, the article Bounded Contexts as a Strategic Pattern Beyond DDD wrote, “Bounded Contexts reflect high-level abstraction mechanisms, which are not the output artifacts of programming languages or frameworks, but reflect the essence of people’s thinking about the domain.”

tactical

For developers, tactics are most useful, such as aggregation, entities, value objects, factories, warehouses, domain events, etc. DDD meets the real technical requirements of software using these tactical component modeling tools. These tactical design tools enable developers to develop software with the mindset of a domain expert

In the strategy section, the idea of bounded contexts is at the core, and is reflected in tactical components, such as entities, which are the smallest contexts, and aggregations, which are larger contexts than entities

But the harsh reality is that a lot of effort is spent on learning these TACTICAL components of DDD, but they are not used in implementation projects. Why? Because transaction scripting is too deep thinking and layered mostly from a technical point of view, there is no abstraction of the domain model, that is, there is no OO abstraction, there is no complete object, no entity, like factory, value object is just a flower in water

This is why although we often refactor the code, it is just a big class smaller class, big function divided into small functions, in accordance with the following code specifications, but for the whole project, there is no substantial improvement

How can these tactical components be substantially improved for complex systems?

Here, structural thinking comes into play

Step 1: Process decomposition, the process by which a complex system is broken down into stages and steps, is also the strength of transaction scripting

Step 2: Object modeling. Although procedural disassembly can reduce the difficulty of development, the domain knowledge is fragmented and the business semantics of the code are not clear. OO is a strong point in this respect, which improves the reusability and cohesion of the code

Combining these two steps, top-down structural decomposition and bottom-up object-oriented modeling, procedural analysis can better clean up the relationship between models, while object model can improve code reuse and business semantic expression ability

conclusion

DDD is a very good methodology, and sometimes we are torn between theoretical purity and practicality. This may be a common struggle in the early stages

DDD has applicable scenarios and transaction scripts have existing advantages

We should not insist on DDD just because people talk about DDD

DDD not only brings a lot of concepts in itself, but also requires the overall quality of the team

There is no silver bullet in software development. You can’t be paranoid about a theory. Actual development is a tough battle, just like mixed martial arts