Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the understanding of domain-driven design". In daily operation, I believe that many people have doubts about the understanding of domain-driven design. I have consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the understanding of domain-driven design?" Next, please follow the editor to study!

My understanding of domain-driven design

You can't get fat at one gulp, and you can't lose weight at once. At present, the development of services follows the patterns of controller, service and dao, and the business logic is implemented in service. Although there are design patterns such as factories, policies, adapters and so on, it is still object-oriented programming. Compared with procedural programming, object-oriented programming has higher requirements for abstraction. It takes a step-by-step process to change the mode of thinking overnight.

The domain division of an existing service system can simply start from the interface provided by the service. First of all, by dividing the interface provided by the service, we can roughly divide the domain that should have, and the existing context of the interface can roughly equate to the bounded context that the service domain should have, and then analyze each interface in the domain, extract the entities and value objects, and finally find out the aggregation root in the domain content, and extract the corresponding factories and domain services. At the end of the analysis, the territorialization transformation can basically be carried out. However, the theoretical basis at this time is still coarse-grained, and some inappropriate places will be found in the process of implementation.

If you want to make it happen, you must first sharpen its tools. In order to make the implementation process more smoothly, we can communicate within the group after the initial division of the domain, on the one hand, the exchange of information between members and the unification of domain terminology; on the other hand, we can draw on collective wisdom to further improve and refine the division of the domain.

1. Domain-Domain

Domain is the abstraction of a series or group of problems in reality and their "solutions". Like a complete mathematical problem, there are complete questions (abstract description of real problems) and solution process. The concept of domain is a virtual concept, the domain more framed a series or a group of abstract content or things, in the domain to solve the problem needs to rely on the boundary context to limit the problem to a certain scope.

2. Bound context-Limit Context

Limit: to solve the problem must be within a certain range in order to solve the problem efficiently and accurately, if you can not delineate a scope, the problem will be infinitely magnified, all solutions will be limited by various conditions. Context: that is, contains the processing logic, contains the data state during the logical processing. Context exists in the domain, defines a scope for solving specific problems in the domain, and provides a context that can be relied on to solve the current problem. Context means to provide an environment, and in domain design it is to provide an environment for the current action. There are multiple actions in a context, providing the preparatory actions required by the current action before each action, and then providing subsequent processing of the results of the current action to form a context.

To understand the context, you can understand it by analogy from existing programming languages and system designs. First from a point, and then to a side.

In the front-end HTML language, the whole HTML document, CSS style and JS script constitute a context. How the content represented by a DIV tag is displayed on the page depends on the location of its parent node, as well as the CSS style set for the current DIV and the CSS style inherited from the parent tag, as well as the JS script specified by the current DIV. The "parent node location", "CSS style set for the current DIV and CSS style inherited from the parent tag", and "JS script specified for the current DIV" are the so-called contexts. Even the content or influence of the self-node within the entire DIV is part of the context.

The concept of this context also exists in Spring. The context in the Spring contains the current running environment, as well as configuration, bean, and other information that can be scanned by the current Spring. When obtaining or initializing a bean in spring, it is important to know the current running environment (web environment or local application), whether the relevant configuration or convention will affect the initialization of the bean, to initialize the current bean dependency, whether there are any actions to be performed after the bean is created (the default method, etc.), and whether there are other bean initializations that depend on the current bean. Here, "runtime environment", "configuration, bean information", "dependency", "initialized method", "dependent" together constitute the context.

3. Entity-Entity

The popular representation of an entity is an bean.java file and a congested model with attributes (unique identifiers and other fields) and actions that give practical meaning to the entity (action: the engineering representation is the method in the Java file). The naming of the method in the entity must be an action description that can describe the actual meaning, and the starting point of the description is to take the current entity as the first-person perspective to describe the actual meaning of the current action.

Because the entity is a congested model with both methods and attribute values, the entity is a stateful object, and it is no longer appropriate to use the singleton pattern provided by the Spring container, which will cause serious thread safety problems, so other methods should be used for initialization. It can be new in threads like database value mapping objects in traditional design, can be produced using factory classes, or can be provided using the prototype model of Spring container, but the supplied objects are empty objects, and all values need to be passed in manually.

An important and necessary field of an entity is the unique identity. So the unique identity is an important field when the entity object is initialized (important, but it can also be empty, such as when creating a new entity. The remaining fields should be loaded on demand and then created or restored when needed (obtained from the basic settings). The important thing to do is to optimize performance and save resources.

An important point: the definition of entity is based on business domain design, and it does not correspond to the table in the database (or the mapping object of the table in the database in the project). Strictly speaking, it can not be one-to-one. However, considering the current situation, it is allowed to correspond the entity to the table in the database. However, after the correspondence, a new problem will be introduced: the mapping objects between entities and database tables will not be clearly distinguished, resulting in obstacles to the understanding of design ideas.

4. Value object-Value Object

A value object is an entity that does not have a unique identity, but it is also stateful, so it does not apply to the singleton pattern of the Spring container, but is more suitable for methods that use new to be created manually when needed. The value object should be as simple as possible, and the actions with practical business significance (that is, the methods in the class file) should be placed in the Entity or domain service as much as possible. The value object should retain only the necessary data verification at most, and the scope should be limited to the inside of the current value object, and do not use external values, variables, etc., but this does not mean that the value object can not have action performance. When an action is performed in order to fulfill a business requirement, and there is no entity or aggregate root to describe (define) the current action, the action should be described by the value object.

In the process of domain transformation, when an "action" can not be described by an entity, but there is no solid argument to prove that the "action" can be described by a value object, the action is first described by the domain service until there is enough argument to support a value object to describe the action with the iterative evolution of the system. Then transfer the description of the action from the domain service to the value object.

5. Polymerization-Aggregate

Aggregation, which combines entities and value objects with strong dependency relevance in the business domain, is a high-level abstract concept.

The simple and concrete understanding of aggregation can be understood as a "lock". Synchronize and lock are locks for program code execution, transactions are locks for database data persistence, and aggregation is locks designed by business system architecture. The objects with strong dependencies in the business domain are grouped under the aggregation root, and the aggregation root is used as the "lock object". All actions start from the aggregation root and end at the aggregation root to ensure the "atomicity" of the business domain design.

However, aggregation in domain-driven design is not only a concept of lock, aggregation does not have mandatory consistency, but ultimately represents the combination of entities and value objects in the domain.

6. Polymeric root-Aggregate Root

The aggregate root can be a single java file or a special class of Entity. The former is not recommended, and the latter is also a common practice, that is, a key Entity is used as the aggregation root of the current domain, and the aggregation root has class attributes and "actions" that give practical meaning to the class. If a key Entity is used as the aggregation root, the aggregation root also has the state. Initialization of stateful objects is costly, so in some simple scenarios, domain services can be allowed to directly access other Entity under the aggregation root, but when it comes to cross-domain business processing, the aggregation root should be used for processing, which is not suitable for direct access to other Entity under the aggregation root.

7. Domain Services-Domain Service

When the aggregate root is a special class of Entity, the aggregation root is a congested object with both attributes and meaningful actions. The action in the entity (or the aggregation root with the entity as the carrier) should be to complete only one action, and do not merge multiple actions into one method, unless the action is also "atomic" in the business domain design. otherwise, it should be split into multiple actions in the entity implementation.

Each action of an entity completes only one "atomic" behavior. When a business operation requires a series of actions on an entity, it depends on domain services to encapsulate a series of "atomic" actions provided by the entity into an independent action and expose it. For the outside of the domain, it is only an action (that is, a call to a method), but for entities in the domain, it is the collective expression of a series of "atomic" actions. For this encapsulation process, the idea of bounding context has been reflected, but this is not the whole of bounding context. In addition to this method of domain service, there will be other logic, such as the recording of operation logs, and so on. These are the contents of bounded context.

For the method of domain service, it is necessary to carry out the corresponding transaction control.

8. Domain event-Domain Event

Domain events can be divided into two categories in understanding: one is abstract "events", which are listed in system design, but do not correspond to any classes, components, frameworks, middleware and other entities in system development, and are de abstract at the design level, biased towards the understanding of domain experts. The other is that the "events" that can be reflected in components and middleware are stylish, and developers can actually see them and control them by technical means, which is biased towards the understanding of developers.

The former "event" can be reflected in the system development as the carrier of the later "event", but it can also be reflected in the system in a non-latter form: it may be a piece of logic in the system.

9. Infrastructure (resource pool)-Repository

In business logic processing, the data processed by the action of Entity (that is, the value of the attribute of Entity) can be obtained from input parameters or from a service or a persistence container (cache, database, etc.). Map the interfaces of these services in the domain | proxy | implement them all into the infrastructure, which is meant to provide basic support for the domain.

The interface of the infrastructure is defined by the domain, and the definition of the infrastructure implementation interface provides basic services for the domain. When implementing the interface defined by the domain, the infrastructure should abide by the agreement of the relevant interface in the domain and ensure the normal implementation of the agreement by technical means. For example, when updating the status of the modified entity to state B, the interface conventions of the domain can only be changed when the status is A. for the sake of ensuring data security and efficiency, the infrastructure should ensure the normal implementation of the interface-related conventions.

10. Anticorrosive coating-ACL

The design significance of the anti-corrosion layer is to maintain the cohesion of the internal design of the domain, not to let the external changes of the domain affect the internal realization of the domain, and make the internal of the domain become chaotic and corrupt. So another understanding of this layer is: adapters designed for the domain. 11. Factory-Factory factory, as a direct production object, is used to complete the initialization and construction of various entities, value objects and aggregation roots. It can not only provide the initialization construction of a single object, but also be competent for the initialization framework of batch objects. But the factory should not undertake any action other than the initialization of the object, if this action has nothing to do with the initialization of the object, it is too small to invade the factory, otherwise the factory will become more and more rotten. In the end, it can no longer be called a "factory".

The factory should exist as a singleton, but the objects produced by the factory: entities, value objects, and aggregate roots should be completely independent objects produced by the template pattern.

Division of entity and value object

Intuitively, the division of entities and value objects is whether there is a "unique identity", but this is not the only standard. There is nothing wrong with strictly dividing it according to this only standard, but in actual development, there are always various situations that need to be "compromised", especially when the existing old projects are territorialized, such restrictions are even more.

The value object can be simply summed up as an anemic and non-uniquely identified object. If an object has a field that can be used as a unique identity, it will not change frequently in the system, similar to enumeration, but not enumeration. it may be configured in the configuration file to configure some identifier objects that are dynamically generated at run time, and have certain "behavior", which looks very vague. It can be defined as either an entity or a value object. In this case, "whether there is a 'unique identification'" is not the only standard for dividing entities and value objects, but dialectically dividing them from the actual situation.

How to demarcate the boundaries of transactions

Based on the existing technology, components and solutions, the persistence of data is still inseparable from the database. Even the new database of NoSQL will involve the problem of atomicity, so the system design can never be separated from the atomic set operation of "transaction".

The transaction boundary in domain design should not exceed an "aggregation root". If it goes beyond the scope of an "aggregation root", it is necessary to consider whether the aggregation is reasonable and whether there is less aggregation. Or is an entity or value object added to the wrong aggregation root? If aggregation is reasonable, consider whether domain events can be used for decoupling? If domain events are used for decoupling operation, the problem is that "transaction consistency is replaced by final consistency", which can only be regarded as a backup solution. To ensure the consistency of strong transactions, adding transactions to the domain service or even the interface level is also a compromise with no availability.

As mentioned in "the division of entities and value objects", the specific division should be based on standards and norms, starting from the actual situation, dialectically dividing the transaction boundary.

What problems does domain design solve?

Domain-driven design focuses on "design" rather than "domain". The division of domain is the means, and the realization of design is the goal. Important participating roles in domain design are "domain expert", "developer", and should also include a "middleman". Why use the word "middleman"? In most companies, the product manager actually acts as a "domain expert" while hiding the real domain experts-- operations, sales, after-sales, etc.-- from developers. Most of the domain expertise that developers can receive is relayed by the product manager, so the product manager who should be the "middleman" invades into the "domain expert" faced by the "developer". So the role of "middleman" is weakened, and the domain knowledge that developers understand is more or less distorted by the product manager. There are only three ways to solve this problem:

Business, product and R & D are involved in demand communication.

The product manager becomes a real domain expert

The product manager understands the design of R & D

The first scheme is not the optimal one, and the more people speak, the less efficient it will be, which will lead to more time and other costs; the second scheme is to put forward higher requirements for product managers to be deeply involved in operational activities and to understand the future direction of business development. The third scheme requires the product manager to have a certain understanding of the specific implementation of the R & D personnel, not to know every method and every line of code, but to understand what objects are in the system and what functions are provided. this corresponds to domain design, that is, product managers are required to understand which entities and other objects in the project, which domain services are provided, and how various fields work together.

At this point, the study of "what is the understanding of domain-driven design" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.