First, practical problems

Scenario 1 Requirements review product greatly: Please help to see what logic XXX function is, if it can support XXX in the XXX scenario I: wait for me to see the specific implementation of the code after a period of time ~ ME: the previous code is written like this, XXX XXX, it seems not possible, but XXX is changed like this, can support

Technical support: Input parameter XXX Output parameter XXX Me: How can this input parameter go through this process? It should not go this way, and then output XXX

Second, the cause of the problem

  1. Technical implementation is a black box for the product, which generally has a deep understanding of the overall planning of the product itself, but may be vague about how the product function details are realized. So in complex scenarios, especially with multiple conditional inputs, you may not know that the code flow will go
  2. Typically, projects are developed by multiple people, and developers have a biased understanding of the code after several iterations of the release

Third, the solution

Abstract the business model (DDD) to visualize the output of the business process. This improves business transparency and code maintainability.

Iv. Solutions

Stage 1: Strategic design

Conduct business domain strategy modeling, organize senior business parties, products and technologies for thinking collision, communicate current product functions and future planning. It mainly discusses what the product is doing, what problems it solves, and what feedback it can bring to users (for example, the core of the trading system is that the buyer and the seller sign a certain contract, how the buyer pays, and how the seller performs the contract. For example, the core problem of the settlement system is to decide who to divide accounts according to the order and how to divide accounts. This stage is mainly to unify the current business cognition, what problems our system is solving. Output:

  1. Typical users: Service objects. Describing a group of people by a person is like describing a group of numbers by a median. Reduce embellishments and avoid misunderstandings. Migrate user portraits based on business changes.
  2. User stories: Describe the story from the user’s point of view, and these stories are the main scenarios in which the product is used.

Summary of problem domains has three main benefits:

  1. Unity of thought. The core value of the domain model is to unify the understanding of the problem by all stakeholders in the project, so as to avoid disconnection between the downstream output and the upstream problem to be solved.
  2. Clear team work. The product can be divided into multiple problem subdomains, to be done by specific teams.
  3. Planning. The product is always evolving, but the core problem we need to solve is in a specific scope, so after extracting the core problem domain, it can reduce the impact of changes on the model.
Stage 2: Tactical design

Design the data model and business process for the phase 1 summary problem area. In the first phase of the domain entity type design, a large number of users and user stories will be output. First, we need to prioritize the stories, with the highest priority being the core scene. Then we need to find entities in these scenes, that is, we need to find the corresponding nouns in a large number of scene descriptions. For example, a high school student places an order to buy review materials (for example, this description is simple), a high school student, order and review materials are the entities we should relate to, and a high school student is an adjective (is an attribute). This is also what the business side should care about, because representing a group of people can help the product better focus on the user), and buying is an action (which will be discussed later). Now that we have the entity, we need to summarize the entity and abstract out the entity type. For example, buyers (bill 3), orders (order) and goods (review materials). At this point, some of you might ask, isn’t this the kind of data model we usually use? It is true that the domain model needs to be persisted to preserve the current state. Personally, how to persist is just one way, we can persist the entity directly to the database, or we can split the entity into a database. For example, if a person has a name, ID number, mobile phone number, address, buyer’s identity and other attributes, we can directly store the entity in a table, or we can divide the entity into multiple tables (user, address, role, etc.) for association according to foreign keys. So the entity type is an abstraction of the entity, and the data model is a persistence of the current state of the entity. In the process of entity type design, we need to summarize the entities in the problem domain, including entity attributes, association relations and states, so as to abstract them into entity types.

Entity type capability abstraction Once you have an entity type, you can abstract the entity capability (or, of course, along with the entity type abstraction). Abilities are the behaviors that are triggered by entities, like the ability to see, hear, and touch, and those are basic abilities. Capabilities can be implemented in the form of entity-type methods or encapsulated using the Manager layer. As long as you follow the principle that entities and capabilities are a highly autonomous entity, changes in entity state can only be triggered by entity capabilities or events. Entity capabilities cannot be implemented in individual business processes, which is not maintainable. Of course, the capability can be expanded horizontally, for example, to see with a telescope, to hear with an earpiece. Therefore, we mainly focus on basic capabilities when carrying out entity capability abstraction, and of course, we should also keep the expansion points of capabilities (in simple scenarios, we can also not implement the expansion points of capabilities). There are many ways to implement extension points, such as policy mode and SPI, as long as one principle is followed: the consumer of capabilities does not need to pay attention to the concrete implementation of capabilities, but only to the abstraction of capabilities.

User stories in the first phase of business process design need to be abstracted into business scenarios, i.e. individual business processes. Specific implementation, such as ordering scenario, need to verify inventory (commodity capacity), lock inventory (commodity capacity), generate order (order capacity). Another example is the payment scenario, which needs to deduct inventory (goods ability), update payment status (order ability), update points event notification (points ability) and so on. The following figure is an example of the payment process, which may be more complicated in reality.

coding


Finally, this is my colleagues and I in the actual business process of some output, may be some subjective views, welcome to correct.

Reference: “domain driven design” mp.weixin.qq.com/s/LY9cT5P6W… Developer.aliyun.com/article/638…