I vaguely remember when I designed a system for the first time, I drew a bunch of UML (Unified Modeling Language) diagrams. Facing the Class Diagram (in fact, the domain model), I struggled for a long time, not knowing how to land it. Because, if you follow this class diagram to the database, it looks strange, a bit cumbersome. But do not according to the class diagram library, and do not know what this class picture.

Ask yourself, how long has it been since you drew a data model and a domain model?

In retrospect, the tangle of I was derived from the I to the domain model and data model of these two important concepts is not clear, previously seen DDD (domain driven design), in a word I feel very good, can serve as a type multiple roles, the role can be explicit (implements an interface or base class), It can also be implicit (specific responsibilities and context determined).

However, every time under the new requirements, the design scheme will delay some time in the data model and the domain model, the root cause is the confusion between the two concepts. Because of this, the design of the data model will be frequently modified in the design scheme or in the development process, because if the underlying logic, concept and theoretical basis is not clear, the system built on it will also have problems, very serious problems.

Drawing on some of the design principles of DDD(Domain Driven Design), I thought it was important to take the time to carefully clarify these two concepts to help you make better design decisions at work.

A conceptual definition

Data model: Persistence-oriented, the carrier of data. It focuses on domain knowledge, which is the core entity of the business domain, and represents the key concepts within the problem domain, as well as the relationships between them. The key of domain model modeling is to see whether the model can express business semantics explicitly, and extensibility is the second.

Domain model: a business-oriented, behavioral vehicle. All businesses are inseparable from data and CRUD of data. Decision-making factors of data model modeling are mainly non-functional attributes such as scalability and performance, and there is no need to over-consider the representation ability of business semantics.

One focuses on the entity, the other on the relationship, and if you think about the way we modeled things in the first place, it becomes a little bit skewed. Data models are designed with entity declarations and business relationships in them, and the two start to get mixed up.

Yes, the two do have something in common, and sometimes the domain model and the data model grow and even converge, which is normal. But more often than not, there is a difference. The right thing to do is to consciously separate the two models and design them separately, because they will have different modeling goals.

As shown in the figure below, the data model is responsible for data storage facing DB, and its essence is scalability, flexibility and performance. The domain model is responsible for the implementation of business logic, and its essence is to express business semantics explicitly, and make full use of OO characteristics to increase the business representation ability of the code.

In fact, the part marked in gray on the way can be subdivided, and the business model can also be split. When it comes to some naming, we will not expand it here. Interested can refer to :PO, VO, DAO, BO, DTO, POJO can be distinguished?

In the daily development process, we do not properly deal with the relationship between the data model and the domain model in many system business designs. Instead, we take the data model as the domain model and the domain model as the data model in the design process.

The domain model is mistaken for the data model

Recently, we have been optimizing the metadata of the low code section, which involves some metadata storage and expansion issues. This logic can be summarized in a nutshell: When designing data forms, users can dynamically configure column properties and dynamically match column properties to corresponding functions based on the corresponding data type.

For this rule, the domain model simply provides column basic configuration information and property configuration information configuration data, as shown in the figure below:



If you follow this line of thought, there are two tables, meta_field_definition and meta_field_attribute. One is used to store the base definition of the column, and the other is used to define the configuration and extension of the column’s attributes.

If we do this, we make the mistake of treating the domain model as a data model, where designing a data table is sufficient. In the original metadata column definition table, add the attribute configuration field fd_attribute to store in the form of JSON, and add the extension table fd_extend_feature on the basis of the basic form (the extension field that is not used as the basis for the current business).



What are the benefits after adjustment:

First, the maintenance cost of a single form is definitely lower than the maintenance cost of multiple tables

Second, the data is more scalable. For example, to support some custom business configuration and function support for a certain data type, if it is a table, we need to continue to add new business support configuration in the property table. But if we change it to a table and it stays the same in the original metadata we can just add the configuration in JSON format in the properties extension.

However, in business code, doing things based on JSON is not so nice. We need to transform JSON data objects into domain objects with business semantics, so that we can enjoy the convenience of data model extensibility without losing the code readability that comes with the domain model being explicit to the business semantics.

Three mistake the data model for the domain model

Indeed, the data model should be as extensible as possible. After all, changing the database is a big project, whether it is adding fields, subtracting fields, or adding tables, deleting tables, all involves a lot of work. Take the example above

Note that the fd_extend_feature extension table is created to facilitate vertical expansion of the table. JSON fields and vertical tables are fine for scaling data storage, but it’s best not to treat these features as domain objects, or your code will not be object-oriented programming at all, but features programming at extension fields. This makes the mistake of treating the data model as the domain model. A better approach would be to convert Data objects to domain objects for processing. However, when processing fields, if the frequent operation of addFDextEndFeature and getFDextEndFeature is a typical error of treating the data model as the domain model.

Four summarizes

In the daily design and development, we should distinguish the domain model from the data model, and let them play their respective roles, so as to structure our application system more reasonably. Among them, the domain model is oriented to the domain object, and should be as specific as possible, with explicit expression of business semantics as its primary task, and extensibility as its secondary task. The data model is data storage-oriented and should be as extensible as possible.

Back to the theme A type can play multiple roles, either explicitly (implementing an interface or base class) or implicitly (assuming specific responsibilities and context determinations),

  • Data model: Persistence-oriented, the carrier of data.
  • Domain model: a business-oriented, behavioral vehicle.

【 Original Address 】 :
The original jump


[Welcome attention] :
Code farmers architecture

Focus on system architecture, high availability, high performance, high concurrency class technology sharing