One article read, DDD landing database design practice

In the past , The software design of the system is based on the database design , When the demand is determined , The team started with database design . Because the database is the only interface of each module , When the whole team has decided on the database design , It can be developed independently according to the modules , As shown in the figure below .

In the process above , To speed up team development , Try not to interact with each other , So as to achieve the effect of independent development . however , As the system grows in size , Business logic is becoming more and more complex , It's becoming more and more difficult for us to ensure that each module is independent and not interactive .

With the continuous development of software industry , Software systems are becoming more and more complex , The interaction between each module is more and more frequent , At this time , The original design process can no longer meet our needs . Because if you want to design the database first , But database design can only describe data structure , It can't describe how the system processes these data structures . therefore , In the process of combing the whole system for the first time , We can only comb all the data structures of the system , Form database design ; next , We have to sort out the whole system again , The analysis system processes these data structures , Form programming . Why can't the design of the whole system be put in place at one time ？

Today, , We have analyzed and designed the system according to the object-oriented software design process . When you start a requirements analysis , First, design the use case model , Analyze the functions of the whole system ; Then we design the domain model , The business entity of the analysis system . In domain model analysis , In the form of a class diagram , Each class can express the data structure through its properties , You can also describe the processing of this data structure by adding methods . therefore , In the design process of domain model , It not only completes the carding of data structure , It also determines the processing of these data structures by the system , In this way, the two tasks are completed at one time .

In this design process , Its core is the design of domain model . Take the domain model as the core , It can guide the database design and program design of the system , here , Database design is a way to realize domain object persistence design .

The idea of domain object persistence

What is domain object persistence ？ In today's mainstream thinking of software architecture design , Object oriented design has become the mainstream idea , In the process of the whole system running , All data exists in the form of domain objects . for example ：

To insert a record is to create a domain object ;

To update a record is based on key Value to modify the corresponding domain object ;

Deleting data is destroying the domain object .

If our server is a super powerful server , That doesn't actually require any databases , Just operate these domain objects directly , But in the real world, there are not so powerful servers . therefore , Domain objects that are not used for the time being must be persisted to disk , And database is just one way to realize this kind of persistent storage .

According to this design idea , We persist domain objects that are not used for the time being from memory to disk . When you need to use this domain object again in the future , according to key Value to the database to find this record , And then restore it to a domain object , The application can continue to use it , This is the design idea of domain object persistent storage .

therefore , Today's database design , In fact, it is to design domain objects according to some corresponding relationship , Conversion to database design . meanwhile , With the big data transformation of the whole industry , Great changes will take place in the future database design ideas , It is possible that a database is not necessarily a relational database , May be NoSQL Database or big data platform . Database design does not necessarily follow 3NF（ Third normal form ） 了 , It could add more redundancy , Even wide watches .

Database design is changing dramatically , But the only constant is the domain object . such , When the system is transforming into big data , The business code can be kept unchanged , What's changing is the data access layer （DAO）. This will make the transformation of big data cheaper in the future , Let's keep up with the rapid development of technology .

Design of domain model

Besides , Here's an interesting question to explore ： Whose responsibility is domain model design , Is it a Requirement Analyst or a design developer ？ In my submission , It's the product of two roles working together . And the organization of agile development in the future , The team will be more flat . In the past, it was the requirement analysts who did the requirement analysis , And then give it to the designers to design and develop , In this way, the quality of software design is low and the structure is bloated . future “ Big front end ” The idea will support more designers and developers to participate in requirement analysis directly , Realize the integration organization form from requirement analysis to design and development . such , Domain model has become a powerful tool for designers and developers to quickly understand requirements .

All in all ,**DDD The database design of has actually become ： Focus on the domain model , How to transform domain model into database design process .** So how to make the conversion ？ In the domain model, it's a class by class , In database design, it is a table by table , So it's the process of converting a class into a table .

The figure above is the domain model diagram of a performance appraisal system , This performance appraisal system first carries on the automatic appraisal , Found a bunch of faults , And then give me another chance , Let the person responsible for the fault plead for his fault . At this time , The person responsible for the fault can fill in an application form for defense , There are several details in the defense application form , Each detail corresponds to a fault act , Every fault action corresponds to a fault type , So it's a domain model .

next , To translate this domain model into a database design , How to do it? ？ Obviously , A class in the domain model can be transformed into a table in the database , Properties in a class can be converted to fields in a table . But the key here is how to deal with the relationship between classes , How to convert to the relationship between tables . Now , There is 5 Two types of relationships need to be transformed , Traditional 4 Kind of relationship + Inheritance relationships .

Conventional 4 Kind of relationship

Traditional relationships involve one-on-one 、 For one more 、 One to many 、 Many to many this 4 Kind of , They exist between classes , It also exists between tables , So you can convert it directly .

1. One to one relationship

In the above case ,“ Defense application form details ” And “ Fault behavior ” It's just a couple “ one-on-one ” Relationship . In this relationship , One “ Defense application form details ” It has to correspond to a “ Fault behavior ”, None of them “ Fault behavior ” The correspondence of can't be a “ Defense application form details ”. This constraint occurs in database design , It can be realized by foreign keys . however , There's another constraint to the one-to-one relationship , That's a “ Fault behavior ” There can be at most one “ Defense application form details ” With the corresponding .

in other words , One “ Fault behavior ” There can be no “ Defense application form details ” With the corresponding , But if you have , There can be at most one “ Defense application form details ” With the corresponding , What this constraint implies is a kind of unique constraint . therefore , Put the primary key in the fault behavior table , As the foreign key of the defense application list , And upgrade this field to the primary key of the defense application form details .

2. many-to-one

It's one of the most common relationships in daily analysis and design . In the above case , A fault action corresponds to a tax official 、 A taxpayer and a fault type ; meanwhile , A tax official , Or taxpayers , Or type of fault , Can correspond to multiple fault behaviors . They form “ For one more ” Relationship . In database design , You can create this through foreign keys “ For one more ” Relationship . therefore , We designed the following database ：

Many to one relationship is relatively simple in database design , But when it comes to programming , It needs to be explored . such as , The above cases , After designing in this way , When inquiring, we often need to inquire the fault behavior at the same time , Display their corresponding tax officers 、 Taxpayer and fault type . At this time , The old design was to add one join sentence . However , This kind of design increases with the amount of data , Query performance will be greatly affected .

in other words ,join Operation is often one of the biggest bottlenecks of relational database in the face of big data . therefore , A better solution is to query the fault behavior table first , Pagination , Then fill in other related information of the current page . At this time , It needs to be in “ Fault behavior ” In this value object, through the property variable , Increase the tax staff 、 The reference of taxpayer and fault type .

3. One-to-many relation

The relationship often expresses a kind of main - The relationship between sub tables . for example , In the above cases “ Plea application form ” And “ Defense application form details ” It's just a couple “ One to many ” Relationship . besides , Orders and order details 、 Forms and form details , It's all one to many . One to many relationship is relatively simple in database design , That is to add a foreign key in the sub table to refer to the primary key in the main table . For example, in this case , The main key in the defense application form is referenced by a foreign key in the defense application form details , As shown in the figure below .

besides , When designing the value object of a program , There should also be a set of attribute variables in the main object to refer to the sub object . In this case , stay “ Plea application form ” There is a collection property in the value object to refer to “ Defense application form details ”. such , When a defense application form is found through the defense application number , At the same time, you can get the details of all its defense application forms , As shown in the following code ：

public class Sbsqd {

    private Set<SbsqdMx> sbsqdMxes;

    public void setSbsqdMxes(Set<SbsqdMx> sbsqdMxes){

          this.sbsqdMxes = sbsqdMxes;

    }

    public Set<SbsqdMx> getSbsqdMxes(){

          return this.sbsqdMxes;

    }

    ……

}
4. Many to many relationship

A typical example is “ User roles ” And “ Function permissions ”. One “ User roles ” You can apply for more than one “ Function permissions ”; And one “ Function permissions ” It can also be assigned to multiple “ User roles ” Use , And that's what makes a “ Many to many ” Relationship . This many to many relationship in object design , Through a “ function - Role Association class ” To describe in detail . therefore , You can add one at database design time “ Role function association table ”, The primary key of the table is the combination of the primary keys of both sides of the relationship , The formation of the joint primary key , As shown in the figure below ：

All of the above are available in domain models and databases 4 Kind of relationship . therefore , In database design , Directly convert the corresponding relationship into database design . meanwhile , In the database design, we need to further refine them . As in the domain model , Whether objects or properties , They are all named in Chinese , It's good for communication and understanding . But when it comes to database design , We need to refine them into English names , Or the initials of Chinese Pinyin , At the same time, we should also determine their field type and other properties such as whether they are empty or not .

Of or relating to 3 A design

The first 5 It's a different relationship ： Inheritance relationship is a key factor in domain model design , But not in database design . How to transform the inheritance relationship in domain model into database design ？ Yes 3 There are options .

1. The first scheme of inheritance relations

First , Take a look at the above cases .“ Law enforcement ” It can be divided into “ Correct behavior ” and “ Fault behavior ”. If there are not many subclasses of this inheritance relationship （ Generally 2 ~ 3 individual ）, And there are not many personalized fields for each subclass （3 Within a ） Words , You can use a table to record the entire inheritance relationship . There is an identification field in the middle of the table , Identify which subclass each record in the table is , The front part of this field lists the fields of the parent class , The personalized fields of each subclass are listed in turn .

The advantage of adopting this scheme is that it is simple , All the data of the entire inheritance relationship is stored in this table . however , It can cause “ The table is sparse ”. In this case , If it's one “ Correct behavior ” The record of , Then the fields “ The type of fault ” And “ Deduct points ” Always empty ; If it's one “ Fault behavior ” The record of , Then the fields “ Bonus points ” Always empty . Suppose there are many personalized fields in each subclass of this inheritance relationship , It will cause a large number of empty fields in the table , be called “ The table is sparse ”. In a relational database , Empty fields take up space . therefore , such “ The table is sparse ” It wastes a lot of storage space , It will also affect the query speed , It needs to be avoided . therefore , When there are more subclasses , Or the case of more subclass personalized fields is not suitable for this scheme （ First option ） Of .

2. The second scheme of inheritance relations

If the law enforcement behavior is inherited according to the type of assessment index , It is divided into “ Assessment index 1”“ Assessment index 2”“ Assessment index 3”…… As shown in the figure below ：

And each subclass has a lot of personalized fields , It is not appropriate to adopt the previous scheme . At this time , Use the other two solutions for database design . One solution is to map each subclass to a table , If there are several subclasses, there are several tables , These tables share a primary key , That is, the primary key generator of these tables is a , A primary key value can only exist in a table , Cannot exist in more than one table . In front of each table are the fields of the parent class , The fields of each subclass are listed below , As shown in the figure below ：

If the business requirement is in front-end query , Only one indicator can be queried at a time , In this way, each query can fall into a table , The plan is the most suitable one . But if the business requirement is to query all the indicators involved in a fault liability person , In this way, all tables must be scanned , Then the query efficiency is relatively low , Not applicable .

3. The third scheme of inheritance relationship

If the business requirement is to query all the indicators involved in a fault responsible person , The following scheme is more suitable , Make the parent class into a table , Each subclass corresponds to its own table （ As shown in the figure ）. such , When you need to query all the indicators involved in a fault liability person , Just query the table of the parent class . If you want to view the details of a record , According to the primary key and type field , Query the personalized field of the corresponding subclass . such , This solution can perfectly meet the business requirements .

in summary , To transform the inheritance relationship in domain model into database design has 3 Kind of plan , And each scheme has its own advantages and disadvantages . therefore , It needs to be evaluated according to the characteristics and requirements of the business scenario , Choose which one is more suitable .

NoSQL Database design

The database design we talked about earlier , Or based on traditional relational databases 、 Database design based on the third paradigm . however , With the development of Internet high concurrency and distributed technology , Another brand new database type was born , That's it NoSQL database . It is precisely because of the high concurrent pressure brought by Internet applications , Using relational database for centralized deployment can not meet the pressure of high concurrency , So that distributed NoSQL The database is developing rapidly .

That's why ,NoSQL The design routines of database and relational database are totally different . The design of relational database follows the third paradigm , It enables the database to significantly reduce redundancy , But from another point of view, database query needs to be used frequently join operation , Low performance in high concurrency scenarios .

therefore ,NoSQL The idea of database design is to kill as much as possible join operation , I'm going to need join Before writing to the database table join operation , Then write it directly to a single table for distributed storage , This table is called “ A wide watch ”. such , In the face of massive data query , There's no need to do it again join operation , Query directly in this single table . meanwhile , because NoSQL The characteristics of database itself , So that it doesn't take up space when it stores empty fields , Don't worry “ The table is sparse ”, Does not affect query performance .

therefore ,NoSQL The routine of database design is , Try to store more fields in a single table , Just avoid... In data query join operation , It doesn't matter if there are a lot of empty fields .

Sample VAT invoice

It is because NoSQL The database has the above characteristics in design , So transform the domain model into NoSQL Database time , The design is totally different . such as , Such a VAT invoice , As shown in the figure above , In the database design, it needs to be divided into invoice information table 、 Invoice list and taxpayer list , When querying, we need to do 4 Time join To complete the query . But in NoSQL Database design , Design it as a table ：

{ _id: ObjectId(7df78ad8902c)

  fpdm: '3700134140', fphm: '02309723‘, 

  kprq: '2016-1-25 9:22:45',

  je: 70451.28, se: 11976.72, 

  gfnsr: {

     nsrsbh: '370112582247803',

     nsrmc:' Jinan Branch of China Unicom Huasheng Communication Co., Ltd ',…

  },

  xfnsr: {

     nsrsbh: '370112575587500',

     nsrmc:' Jinan Branch of China Unicom Huasheng Communication Co., Ltd ',…

  },

  spmx: [

     { qdbz:'00', wp_mc:' Bluetooth headset Car talker S1 Bluetooth headset ', sl:2, dj:68.37,… },

     { qdbz:'00', wp_mc:' Car charger New online ', sl:1, dj:11.11,… },

     { qdbz:'00', wp_mc:' Protective shell Fenimonium iPhone6 Electroplated shells ', sl:1, dj:24,…  }

  ]

}
In this case , about “ one-on-one ” and “ For one more ” Relationship , In the invoice information table, through a type of “ object ” To store , such as “ Buyer taxpayers （gfnsr）” And “ Sales tax payers （xfnsr）” Field . about “ One to many ” and “ Many to many ” Relationship , Through a type of “ An array of objects ” To store , Such as “ Product details （spmx）” Field . In such an invoice information table, you can query all invoices , No more join operation .

Again , use NoSQL How to realize the design of inheritance relationship in database ？ because NoSQL The characteristics of the database itself decide not to worry “ The table is sparse ”, At the same time, it should be avoided join operation , So it is more suitable to adopt the first scheme , That is, the entire inheritance relationship is put into the same table for design . At this time ,NoSQL Each record in the database can have different fields , It can be designed like this ：

{ _id: ObjectId(79878ad8902c),

  name: ‘Jack’,

  type: ‘parent’,

  partner: ‘Elizabeth’,

  children: [

    { name: ‘Tom’, gender: ‘male’ },

    { name: ‘Mary’, gender: ‘female’}

  ]

},

{ _id: ObjectId(79878ad8903d),

  name: ‘Bob’,

  type: ‘kid’,

  mother: ‘Anna’,

  father: ‘David’

}
The above case is a user profile , There are two records ：Jack And Bob. however ,Jack The type is “ Parent ”, So its personalized field is “ partner ” And “ children ”; and Bob The type is “ children ”, So his personalized field is “ father ” And “ mother ”. obviously , stay NoSQL Database design will become more flexible .

summary

Landing the domain model to the system design, including 2 Part content , In this paper, the first part of the content is rehearsed —— from DDD Implementation to the whole process of database design ： Conventional 4 These relationships can be transformed directly ; The relationship of inheritance has 3 Design plan ; convert to NoSQL Database is a completely different way of thinking .

With DDD Guidance of , It can help us sort out the relationship between data , And the operation of data . More Than This , In the face of big data transformation in the future, we will be more relaxed .

Brief introduction of No ： Feng Tao , Once worked for Alibaba , Daily fresh and other Internet companies , Technical director ,15 Years of E-commerce Internet experience .

Last , Will oneself 15 Micro services in 2010 , High concurrency ,JVM tuning , Online troubleshooting experience into e-books for you , common 130 page . Absolutely dry ！ A friend who hasn't received it , Hold on ！

If you are interested in learning more about the content and related learning materials, please like the collection + Comment forwarding + Pay attention to me , There will be a lot of dry goods in the back . I have some interview questions 、 framework 、 Design materials can be said to be necessary for programmer interview ！ All the information has been put into the network disk , If necessary, please download ！ I replied by private letter 【666】 Free access to