This instrument follows on from the previousFigure of speech - all anti-DDD models are garbage", follow the public number (Old Shaw wants to be a foreign language big brother) for information:
Latest Article Updates;
DDD framework source code (.NET, Java dual platform);
Add a group to chat and exchange modeling analysis and technology implementation;
Video and live streaming on B-site.
contexts
When I communicate with developers about DDD modeling ideas, I often encounter a difficult problem, that is, many experienced developers, always with the technical thinking to understand the business, ta brain can not purely outline a clear boundary representing the image of the business entity. One of the most obvious phenomenon is the habitual use of relational databases in the "relationship" to map the relationship between the business model, once with the "relationship" to think, then the "boundary" is very difficult to have a clear picture. Once you think in terms of "relationships", then "boundaries" will hardly have a place. For developers who do not have much experience with "relational databases", it is easy to understand what is called "clear boundaries".
The Three Paradigms of Relational Databases
Here we start with a list of three paradigm definitions for relational databases:
- First Paradigm (1NF): ensure that the values in each column are atomic, i.e., the values in each column are not subdividable.
- Second Paradigm (2NF): on the basis of satisfying the first paradigm, ensure that every column in the table is fully dependent on the primary key and not partially dependent.
- Third Paradigm (3NF): Based on the fulfillment of the second paradigm, it is ensured that every column in the table does not depend on non-primary key columns, i.e., pass dependency is eliminated.
More colloquially:
- First Paradigm (1NF): only one value can be stored per field, no duplicate columns.
- Second Paradigm (2NF): on the basis of satisfying the first paradigm, all non-primary key fields must be fully dependent on the primary key and not only partially dependent on the primary key.
- Third Paradigm (3NF): on the basis of satisfying the second paradigm, there can be no dependencies between non-primary key fields, which must depend directly on the primary key.
And fulfill several key purposes of the Triple Paradigm:
- Eliminate data redundancy: Reduce data duplication and save storage space by ensuring that each data item is stored only once in the database.
- Improve data consistency: After reducing data redundancy, only one place needs to be modified when data is updated to avoid data inconsistency.
- Simplify data maintenance: Reduce data anomalies and complex maintenance operations through standardized design, making the database structure clearer and easier to manage and expand.
DDD Thinking vs Tri-Paradigm Thinking
Suppose we are designing a system with elements of users, roles, and departments. If we base our thinking on relational databases, the probability is that the design will look similar to the following figure:
If we design a system that fully satisfies the three paradigms of relational databases, then it can be deduced that basically all the entities of the entire system will be directly or indirectly "related" to each other, and the diagram will be as intricate as a spider's web, which is the opposite of the concept of DDD.
Therefore, from this point of view, "the relational database tri-paradigm model is an anti-DDD model".
If we use DDD thinking, then "connecting lines means they are a whole", and to make the boundaries clear, we need to eliminate the connecting lines, then the design of the diagram, the probability is like the following:
Of course, you must have questions, there is a relationship between users and roles objectively ah, you remove the line, then the relationship can not be expressed, the above diagram does not reflect the complete design, in fact, if we expand the "user aggregation" detail diagram, you will find that we put the "relationship" to the "user aggregation inside", you need to note that there is an additional entity called "user role" which is related to the "user role". "Relationships are placed inside the User Aggregation. Note that there is an additional entity called "User Role", which is not the same as the "Role Aggregation". It is not the same concept as "Role Aggregation".
By this point, I think you can also spot some characteristics of DDD thinking:
-
No joins between aggregates, keep boundaries clear
-
Aggregation internally satisfies the relational database triple paradigm
-
In order to achieve no joins between aggregates, some "redundant" entities are generated
Costs and benefits
If we use the DDD pattern to design the system, the cost is that the data will be "redundant" to a certain extent, and these redundant entities need to be kept consistent through the "event-driven" way, while the benefit is that the system is clearly divided into multiple boundaries. The benefit is that the system is clearly divided into a number of boundaries and domains, and the complexity is organized like "clutter" in a number of "storage boxes".
In addition, regarding "redundant data", we are looking at it from the perspective of a "relational database". If we look at it from the perspective of DDD, the "user roles" in the previous model diagram are the attributes that objectively exist in the "user aggregation". If we look at it from the DDD perspective, the "user role" in the previous model diagram is an objectively existing attribute of the "user aggregation", so it is not redundant. You see, once we switch to the DDD perspective, we will find that things become very natural.
The real world is full of redundancies.
If you still don't find the above example convincing, then you can observe the situation in the real world, and you will find that the phenomenon of information redundancy is common, for example, my cell phone address book is redundant with your name and cell phone number because "my address book" is the property of the objective "me", and the real world is full of similar examples. "The real world is full of similar examples.
reach a verdict
If you expect to enter the world of DDD as soon as possible, then when analyzing requirements and designing models, you must forget about the existence of relational databases and the triple paradigm as much as possible, and even if you want to apply the triple paradigm, you should only apply it inside your model, and never use it to express the relationship between "aggregates", because "Aggregates" are independent and have clear boundaries.
