Data Model Design Methodology for Domain Modeling | JD Cloud Technical Team

This article provides readers with a methodology for designing business models to data models through actual business requirement scenario modeling cases, which is used to guide how to transform and abstract business models to data models in actual development, and to improve the usability and scalability of the designed data model Suggested reflections are provided. Through the article, readers can gain a referential methodology for abstracting business models from data models, and minimize the risk of model adjustment or model overturning and reconstruction in response to changes in later business requirements. This article can focus on the modeling implementation process, and constantly abstract and optimize your own data model for your actual business scenarios.

1. Background

From the perspective of R&D personnel, technology is more about empowering business. At the same time, R&D personnel can also improve their own technology through business model design. They are more technically controlled and seek to have more technology stacks. However, I will not discuss specific technologies today. I am going to change my thinking mode to share some of my experience in business development, and combine practical cases to illustrate the methodology of data modeling for business scenarios.

In their daily work, developers participate in PRD reviews, listen to product managers tell user stories, and raise various requirements. After the review is over, you will generally devote all your brains to design and development, and database table design is an indispensable process. For familiar business modules, the data table design can be easily completed through demand analysis, but for unfamiliar business fields, it may go through multiple rounds of PRD analysis to sort out a set of data table structure foundations, and then add fields to it to complete Basic data model design. In this process, I often feel that there is no theory to refer to, and sometimes I even have doubts about the designed database table, and constantly consider whether the design is in line with the business, whether the table structure design is universal in the later stage, and whether the relationship between the tables is appropriate and reliable. extensions and more. Today, let’s talk about some thoughts on data modeling in actual business development.

A good methodology must tell you how to independently analyze and solve problems when you face a brand new business scenario or an unknown field.

2. Nouns

Domain : It can be understood as the business domain corresponding to the business scenario in traditional software requirements analysis, such as common e-commerce, logistics, transportation and other fields.

Subdomain : Part of the business domain of the domain, such as some order, payment, inventory and other subdomains of e-commerce.

Modeling : Mapping and abstraction of business domains.

3. Thinking

Design Thinking Patterns for Object-Oriented Analysis:

Figure 1. Thinking from the user perspective to the development perspective

4. Methodology

4.1  Implementation steps

1. identification object;
2. organization object;
3. Define relationships between object models;
4. Improve model details (attributes, status);
5. domain model to data model mapping;

4.2 CASE practice (community group buying - pre-line scheduling modeling case)

(1) PRD requirements description

The pre-arrangement system obtains the group order data from the OFC system: every afternoon before the order cut-off, OFC pushes a data that needs to be pre-arranged on the day. These data include each group order (production order) that has been formed and the current time The product data of the group order, which includes the group order that has been canceled on the day (that is, the quantity of all products is 0). At the same time, after the cut-off order, OFC will push the cut-off group order data again, which includes the group order that has been canceled on that day (the quantity of all products is 0);

Creation, update, and deletion of group order data: If the issued production order number does not exist in the pre-arrangement system, create group order information; if the issued production order number exists in the pre-arrangement system, update the order information Quantity, receiving address of the group order, latitude and longitude, group leader ID, name, phone number and other information; if there is a new product, add the product data under the group order; if the quantity of the group order is updated, the number of all products below it Both are 0, which means that the group order has been cancelled, the group order will be logically deleted, and the binding relationship between the group order and the corresponding line will be canceled at the same time; the updated product quantity is the current quantity of the updated product, and the scheduling time will not be updated. and actual quantities.

(2) Identify objects

Note：

1. Reuse or modify existing models (such as: transportation demand, plan, inquiry, statement, financial bill, etc.);
2. A list of concepts within the industry and company (such as: community group buying, sorting, scheduling, inquiry, billing, etc.);
3. noun.

Recognized objects:

OFC group order pre-arrangement data production single commodity quantity pre-arrangement system group order receiving address latitude and longitude group leader ID name telephone line current quantity of commodity actual quantity when dispatching

(3) Organization object

Note：

1. Multiple uses, repetition, and ambiguity: it boils down to an object model;
2. Plural: students --> student boils down to an object model;
3. Attribute: It can be attributed to the characteristics of the object model. It is not upgraded to an object alone. However, in special scenarios, such as the classification of articles, it can be an attribute of articles. However, when the classification has sub-attributes, such as sub-attribute tags, then Classifications can be upgraded individually to object models. Similar to designing a database table, whether it is designed as a field or a new table is designed.

analysis object:

1. OFC: system
2. Group order: production order, group order receiving address, latitude and longitude, group leader ID, name and phone number
3. Pre-arrangement: pre-arrangement system, pre-arrangement model line
4. Commodity: Commodity Commodity Quantity The actual quantity of the current quantity of the commodity when dispatching

(4) Define the object model relationship

Note：

1. foreign key
2. Relationship: one-to-one, one-to-many, many-to-many, relationship transfer

Analysis relationship:

1. "Cancel the binding relationship between this group order and the corresponding line at the same time" -----> The pre-arranged line includes multiple group orders, pre-arranged line VS group order = one vs many
2. "If there is a new product, add the product data under the group order" -----> There are multiple products under the group order, group order VS commodity = one vs many

Figure 2. Relationships between models

(5) Improve model information (attribute status)

Note：

1. Sub-domain: sub-object information of the model object, such as: employee model, address library model, employee salary model, etc. under the store model.
2. Attributes: Characteristic representations of model objects
3. state: state machine
4. Boundary: The interactive part between object models, clearly distinguishing which belongs to A object and which is B object

Complete object model:

Figure 3. Object model (simulated field information)

(6) Domain object to data model

Note：

1. Derivation : An association, inheritance, and mapped relationship between data models. For example, the "transportation task code" attribute in the "pre-arrangement model" belongs to the model attribute of the dispatching domain, which will be associated with the dispatching domain system later, so the transportation task code is taken as a derived attribute of the "pre-arrangement model".
2. Redundancy : ① Low-level redundancy (display) – the model relies on external model attribute fields for display and use. At this time, there is no need to associate query or obtain through IO; ② Advanced redundancy (calculation) – such as external models have unit price and quantity attributes and are not stable change, the model can rely on its calculation results, eliminating the need for secondary calculation logic;
3. Extended table : ①Vertical splitting of the data model to reduce large objects; ②Fields that do not change frequently can be placed in the extended model;

Partial model design drawing of community group buying cable:

Figure 4 Final data model diagram

5. Expansion

5.1 Thinking in the domain model design stage

Object : domain model object, the object model analyzed in the above case;

Function : which business functions are divided into domains (microservices) or subdomains (modules)

Interface : the interface capability that the service should expose;

5.2 Methodology

verb + object <----> method interface + object

• Separation of business function operations and entity objects makes it easier to divide microservices;
• Which interfaces should a microservice expose;
• Domain context boundary, which domain the interface should belong to provide.

Figure 5 Domain model call relationship diagram

V. Conclusion

A good methodology must tell you how to independently analyze and solve problems when you face a brand new business scenario or an unknown field.

Author: JD Logistics Zheng Penghui

Source: JD Cloud Developer Community