当前位置:网站首页>One article read, DDD landing database design practice
One article read, DDD landing database design practice
2022-07-06 09:26:00 【Java domain】
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
边栏推荐
- Nacos installation and service registration
- The five basic data structures of redis are in-depth and application scenarios
- Solve the problem of inconsistency between database field name and entity class attribute name (resultmap result set mapping)
- Pytest参数化你不知道的一些使用技巧 /你不知道的pytest
- Using label template to solve the problem of malicious input by users
- SimCLR:NLP中的对比学习
- Servlet learning diary 7 -- servlet forwarding and redirection
- Redis之Geospatial
- Publish and subscribe to redis
- Master slave replication of redis
猜你喜欢
Selenium+Pytest自动化测试框架实战(下)
英雄联盟轮播图手动轮播
Mathematical modeling 2004b question (transmission problem)
Master slave replication of redis
Advanced Computer Network Review(3)——BBR
Selenium+Pytest自动化测试框架实战
A convolution substitution of attention mechanism
IDS' deletion policy
Redis之cluster集群
[oc]- < getting started with UI> -- common controls uibutton
随机推荐
Redis' performance indicators and monitoring methods
Opencv+dlib realizes "matching" glasses for Mona Lisa
LeetCode41——First Missing Positive——hashing in place & swap
Design and implementation of online shopping system based on Web (attached: source code paper SQL file)
有软件负载均衡,也有硬件负载均衡,选择哪个?
Improved deep embedded clustering with local structure preservation (Idec)
[OC foundation framework] - string and date and time >
Servlet learning diary 7 -- servlet forwarding and redirection
运维,放过监控-也放过自己吧
AcWing 2456. 记事本
xargs命令的基本用法
[shell script] use menu commands to build scripts for creating folders in the cluster
Parameterization of postman
Redis cluster
Global and Chinese market of bank smart cards 2022-2028: Research Report on technology, participants, trends, market size and share
Once you change the test steps, write all the code. Why not try yaml to realize data-driven?
【图的三大存储方式】只会用邻接矩阵就out了
IJCAI2022论文合集(持续更新中)
基于WEB的网上购物系统的设计与实现(附:源码 论文 sql文件)
[oc foundation framework] - < copy object copy >