0 foreword

Recently, due to the need of work, I came into contact with a project of online business bank. The corresponding business model design in the project is the most complex of all the models I have seen in my three years of work. Therefore, during the short holiday of May Day, I reviewed the knowledge related to domain modeling and had some additional thoughts on the design of domain model.

On the Domain side, there’s a book called Domain-Driven Design by Eric, which has a 4.15 rating on Goodreads (quite high). Here’s a passage from the book:

“Software developers are almost always focused on technology as a demonstration of their capabilities and a measure of success…… This is a difficult task when the field is complex and requires the joint efforts of highly skilled personnel. Developers must delve into the domain to gain business knowledge. They must hone their modeling skills and master domain design. “

The ability of domain design emphasized in the book is a reflection of the comprehensive ability assessment of technical personnel. This is, in my opinion, a T-1 capability in the direction of software engineering. The so-called domain modeling is a methodology that strengthens the thinking of developers and forces them to think deeply through daily practice, and enables developers to form a structured way of thinking through constant practice in this process.

However, it is important to note that the definition of the domain model itself varies somewhat between methodologies and schools. There are also multiple approaches to domain modeling. However, there is no right or wrong way to seek common ground while reserving differences.

In this article, I will focus on my understanding of domain modeling and introduce some basic domain modeling knowledge. It is a summary of the May Day holiday and the work experience of the past few years. We’ll also briefly talk about how we can think about domain modeling in our daily lives. I hope I can help you.

ok, start with why.

1 Domain Model

1.1 What is the Domain Model

Before we start with why, let’s insert what to introduce the basic concepts of the domain model.

A domain model is a visual representation of conceptual objects within the domain or objects in the real world. Also known as conceptual model, domain object model, analysis object model. It focuses on analyzing the problem domain itself, uncovering important business domain concepts, and establishing relationships between business domain concepts. — from Baidu

It’s a little confusing to explain, but simply put, a domain model is a model that describes the thing itself. It focuses on the characteristics of things, the connections between things. In daily business development, the scenarios we face are diverse, so we may acquire different characteristics for the same thing in the modeling process. So somebody A, he’s an employee, he’s A programmer, he’s A man, he’s A father. In a particular scenario, we can only extract the specified features.

How do we understand the relationship between domain models?

For example, in the case of this person, A, the characteristic we want to extract this time is the father. Father and mother, husband and spouse, the relationship is 1 to 1. Monogamy. The relationship between father and child is 1 to N, so a father can have one child, or he can have multiple children. The relationship between mother and child is also 1 to N. So the connection between the family of three can be simply represented by this picture:

Of course, there are many other ways to graphicize domain models, such as UML class diagrams, state and state diagrams, time diagrams, etc., which are not described here.

1.2 Why learn domain models

“Infrastructure determines superstructure” — Marx.

Our ancestors taught us that great oaks from little acorns grow, and told us to build tall buildings with deep foundations. If software is likened to a tall building, then the domain model can be understood as the infrastructure underneath the tall building.

Architecturally, Domain models are at the bottom of the application architecture, the Domain layer in the figure above, which covers model governance, process abstraction, process governance, and so on. We can clearly see that if the domain model is not well controlled, it is equivalent to the foundation of the building is not well laid, and the subsequent construction or maintenance costs are unimaginable.

Problem space and Solution Space are a set of general Problem analysis and Solution methodologies. If we understand it in terms of Problem space and Solution space, what domain model does is in the stage of Problem space, while Solution space corresponds to system model.

How do we distinguish between a domain model and a system model?

Quite simply, domain models focus on the thing itself and are highly abstract. To the system model, is to the specific design stage. For example, someone A above, who has three children, how do we model the system during the design phase? There are three possible solutions:

  • The father table contains multiple child fields, child 1, child 2, and child 3, which are used to store information about children
  • Father and child are two separate tables, associated by foreign keys
  • Store it as a string, such as a large JSON string, in the parent’s table

These are three different implementations, but at the domain model level, it’s still father and child, 1 versus N.

Therefore, we derive the system model and design the corresponding solution through the domain model. If the initial modeling of the domain model is a big problem, it can cause developers to do a lot of useless work.

But why do we want to do development according to this process, language has a process oriented and object oriented division, we can correspond to the development process, can also understand the process oriented and object oriented (model) division. Do not do analysis and design in the early stage, there is a preliminary implementation ideas in my mind, directly operate the keyboard a shuttle, is not very carefree? And from the point of view of physics, the evolution of the system, as time goes by, the degree of chaos is always increasing (entropy increase), is it possible to say that the domain model can achieve the anti-science ability of entropy reduction?

Let’s recall these two scenarios and see if you’ve ever encountered them:

1. After receiving PD’s demand, I took a glance and picked up the keyboard with a shuttle. After a period of shuttle, I found that there was a problem in a certain link, which may be the insufficiency of PD’s demand or the limitation of your implementation plan. We have to overturn the results and start from scratch. Or write a bunch of really disgusting code and tell yourself you can refactor it later.

2. After the application has been online for some time, PD wants to make a small optimization and comes to discuss with you. You realize it’s a small optimization, but it’s a big change. The reason is that your previous design scheme could not support this change well, or it was not well connected with PD demand. As a result, the code gets messy and hard to maintain.

Of course, PD may feel guilty when she sees you working overtime every day for her minor modification. She will have a cup of milk tea on the left and a cup of juice on the right, which will lead to a workplace marriage.

If we choose to use domain modeling, can top-down design solve these two problems?

The answer should be no. In order to solve the above two problems, in addition to improving the modeling ability of development, the system design ability, PD’s understanding of models, and the effectiveness of communication between PD and RD are all factors worth considering. However, through domain modeling, we can at least ensure that the implementation and hierarchy of the code are relatively scientific and stable and conform to industry norms. In the process of domain modeling, clear demarcation of domain boundaries is of great help to the subsequent improvement of system stability, dependency differentiation and business logic clarity. (Domain modeling ability in a BU of Ant Financial is one of the assessment criteria for high P of application architecture)

Therefore, good domain modeling is not only to improve the overall quality of developers, but also to design a sustainable and stable system that can be maintained at low cost. A design guideline from domain model to system model can help reduce the discrepancy between software design and reality requirements.

1.3 How to Model the domain

There are several ways to do domain modeling. It is important to note that domain modeling is not a pure technique that can be learned to design a perfect model. Designing good models depends on a lot of experience and thought. Some common analysis methods are presented below, and then we choose a more interesting method for further introduction.

Common analysis methods

  • Use case analysis
  • DDD (Domain-Driven Design)
  • DoDAF
  • Java Modeling In Color With UML
  • Pegasus Model (inside Ant Financial)

example

Use case analysis, for example, is the most common and simplest method of analysis.

Use-case description: Taurus publishes an article.

This use case seems a little too simple. From a subject-verb-object perspective, the subject is Taurus, the predicate is post, and the object is article.

Here we add that a domain model is a model, and the model itself has attributes. For example, if someone A is A person, there will be attributes such as age, sex, height, etc.

To introduce the concept of attributes, we add attributes to the use-case description above.

Use-case description: Taurus has published an article on domain modeling.

Subject: Taurus, noun, can be abstracted as domain model; Predicate: release, verb, can be abstracted as model relation; Attributive: domain modeling related, adjective, can be abstracted as model attributes; Object: article, noun, can be abstracted as domain model;Copy the code

Of course, the actual use case description will be much more complex than the above, and there will be more mapping between specific language and use. For example, we can not only abstract the attribute into the attribute of the object, but also abstract it into the association model of the object.

At this point, we can abstract out a simple domain model based on the simple use-case description above, as shown in the figure:

The whole process is very clear and understandable. Let’s abstract the specific steps:

  • Collect the use case description collection
    • A set of use cases that require literal description
  • Find the concept
    • Conduct linguistic analysis of use case descriptions and identify nouns
  • Adding model associations
    • When there is semantic connection between nouns, there is usually a model connection. For example, the above publication links the two nouns Taurus and article
  • Attribute is perfect
    • Adjective perfect, such as domain-modeling-related above, if the article has a tag attribute, then its value in our use case is domain-modeling-related.

These are the four simple steps, but the actual engineering of domain modeling is far more complex. For example, there are subdomain division, model combination and other means.

Now let’s look at an interesting example, from the paper “Object-oriented Analysis from Textual Specifications”, which is translated into Chinese as “Object-Oriented Analysis Based on Textual Specifications”. How to analyze use case description from semantic and syntactic perspective through natural language processing technology, and then extract domain model through program.

Use case description:

the Static Requirements are: Vendors may be sales employees or companies. Sales employees receive a basic wage and a commission, whereas companies only receive a commission. Each order corresponds to one vendor only, and each vendor has made at least one order, which is identified by an order number. One basic wage may be paid to several sales employees. The same commission may be paid to several sales employees and companies.

the Dynamic Requirements are: A monthly payment is made to vendors. When a vendor makes a sale, he/she reports the order to the system. The system then confirms the order to the customer, and orders are delivered to customers weekly.

There are static requirements and dynamic requirements, static requirements and dynamic requirements. The main idea is:

Static requirements: Suppliers may be salespeople or companies. Salespeople receive a base salary and commission, while the company only receives commission. Each order corresponds to only one supplier, and each supplier has made at least one order. Orders are identified by order numbers. A basic salary can be paid to several salespeople. The same commission can be paid to several salespeople and companies.

Dynamic demand: monthly payment to the supplier, when the supplier makes a sale, he will report the order to the system. The system then confirms the order to the customer. Orders are delivered to customers on a weekly basis.

This example will be a little more complicated than the first example, so let’s go back to the four simple steps above. Mark the following nouns: Vendor, order, sales employee, company, order number, basic wage, commission.

Some of these nouns are subjects and some are objects. With verbs, we can draw a picture like this

Some nouns can be attributes of other nouns. For example, sales staff and base salary. Base salary can be an attribute of a salesperson. It is written that such attributes can be extracted by analyzing the relationship between aggregation and binary association in the model. You get the following picture:

2. Domain modeling and daily life

Is learning domain modeling only useful to developers?

No, domain modeling is essentially a high level of engineering abstraction. If we look at life as a project, we can model life as a domain. Or if we have a problem or want to get something done, how can domain modeling help us in this process?

What factors do we need to consider in order to solve a problem? Problem, goal, current situation, plan.

These four models were highly abstracted, and we modeled them. If the solution works, what is the problem – goal – status – solution domain model called?

We can think of it as our model, or principle.

Software engineering teaches us engineering thinking, and domain modeling trains us to be highly abstract.

After graduating from university, I realized the help of these knowledge and skills in my daily life, and initially had the concept of modeling. So much so that a year or two after graduation, when I was talking to my friends, the word model often came up. It wasn’t until later that I read Ray Dalio’s Principles that I realized that this is a model of doing things — Principles.

What is the benefit of domain modeling to get principles for everyday life?

For example, we compare the memory part of the human brain to a disk. You see a problem, you solve a problem, you tell yourself you can’t repeat a mistake, so you write it down. Some time later, you encounter a similar problem and repeat the above steps to record the event to disk.

What’s the downside of this? Over time, your memory will fill up with all kinds of instantiated mistakes, and when you want to recall something, you’ll have to scan the data on your disk, which can take a while. Add in the fact that the human brain has a memory curve, and early mistakes can be quickly erased by the data.

But if you start thinking abstractively early on, you’ll find that over time you’ll have fewer and fewer “principles” to establish, and the ones you already have will get better and better.

Therefore, it is helpful to improve your abstraction ability to learn domain modeling. To be a better man.