Domain Driven Design series: The nature of the logical organizational model in three domains

In the enterprise Application architecture pattern, three kinds of domain logical organization patterns are put forward: Transaction script, domain model and table module. Many people look at the foggy, many people say the indefinitely, the main reason is not from the project level of analysis and design experience, only a single project module development experience of people difficult to understand in place.

1. Transaction script:

The understanding of transactional scripts is actually the simplest, but many people do not know, feel more difficult to understand than the domain model, also does not correspond to the code. But this is only an illusion, how can the simplest domain logical mode do not understand, but the most complex domain model of the pattern understand it.

Let's look at the phrase " use process to organize domain logic " in the Enterprise Application architecture Model , in fact, the transaction script is the process to look at the requirements, the demand side and the developers at this stage are keen on the core is "how this function is a process", The two agreed to use code to simulate the rough process. So most people are unconsciously applying transactional scripting patterns. Simply put is the need to use the process code to simulate the user's surface . If this project continues, then the question is:

(1) The user is not very clear about the demand, the demand will certainly be with the user's ideas change and constantly change. Even if you do not think carefully as the demand side, but simply state the surface of the process, you will often due to their occasional deep thinking or more flaky ideas and constantly changing the needs.

(2) The code of the transaction script pattern is procedural, what calls are required, common data source communication, mail service, application-level log security and other code are mixed together, if the requirements change, it is difficult to adjust.

This is the general state of many projects, because the root cause of the problem is not in- depth analysis and understanding of the needs of users , so it is not with what framework and layering, to engage in some specious entities or using the IOC and AOP technology to achieve the function. Or to seek solutions from the root cause, so the field-driven design emphasizes the common language , in order to work with the needs of the specific areas of deep analysis, such demand analysis and model design has a higher stability, not because the demand side of the brain pumping and storms lead to a large change in demand.

Once you understand the core of the transactional scripting pattern, you are well aware of the scope of the transaction script:

(1) Domain logic itself is a number of simple processes.

(2) The demand is very simple, even if it seems superficial enough to go deep.

Here to remind you, to learn the domain-driven design do not run, do not forget that the domain logic itself is the root of all analysis and design. In particular, beginners should not put the non-domain layer and application layer of the various framework technology and components such as mixed into the study. In the process of analysis and design, at least two points must be adhered to:

(1) Do not focus on the presentation layer and the data source layer at this time

(2) As much as possible from the project as a whole perspective of the problem, not only the developer's perspective to think.

Transactional scripting can still use a variety of technologies and frameworks, but no matter how you name files and what components you use, you still organize your business logic in a process. The design result of organizing domain logic in transaction script mode is necessarily based on a series of flowchart .

2. Table module:

The table module no longer takes the process as the core of the organization domain logic, but instead takes the data as the core of the domain logic . Some teams that are poisoned by transactional scripting patterns may realize that the process changes are unpredictable and often do not go or fail to work on demand analysis, thus capturing the more stable data portion of the business logic from a technical standpoint. That's the only thing. Patterns using table modules often have the following two results:

(1) The result of the design is mainly the E-r diagram or the e-r map of the skin .

(2) The natural use of data models but insisted that the domain model.

It is also natural to get the application scope of the table module:

(1) The business logic itself is a simple processing with data as its core.

(2) The process of business logic is very simple, and this is consistent with transactional scripting.

3. Domain Model:

The domain model simultaneously takes behavior and data as the core of the domain logic . As a result, you can't just care about process and surface requirements like transactional scripting, and you can't just care about data like a table module. The question is finally clear:

(1) Transaction scripting mode does not (or evade) deep analysis requirements.

(2) The table module emphasizes the data and does not get a sufficient domain model.

(3) The domain model model uses the common language to solve the requirement problem, and adopts the process and data to solve the domain logic organization.

It's really not as complicated as it is, because it's inherently simple. Due to the nature of the domain logic itself, the following two tendencies of the domain model are often generated:

(1) Form a domain model of a transactional script pattern, which is determined by the nature of the domain logic itself, even though it looks very similar from the code, but with the advantage of more stable and less demanding changes.

(2) A domain model of form-like module model. Other ibid.

The advantages are really too obvious. I really can't refuse. This is not a technical problem, this is a requirement analysis and model design problems, I really can not make these simple concepts more complicated. In the process of using and perfecting the requirement analysis of the common language, we get the more stable demand analysis through several in-depth analysis and iteration, in the process of perfecting design, we divide the aggregation, subdomain and boundary context to simplify our design by using and recognizing the concepts of entity, value object, domain service and domain event. This is the natural result of continuous depth, refinement, and iteration in the context of domain logic.

Domain Driven Design series: The nature of the logical organizational model in three domains