This instrument follows on from the previousThis is how I "PUA" people in order to land DDD.Welcome to my public number of the same name.
/s/DjC0FSWY1bgJyLPIND5evA
What's the most important thing
If you have read the previous articles carefully, then you must know our core logic:Domain-driven is a valueThe value is that the clarity of the "domain (boundary)" is the key to controlling the complexity of the software design.most importantlyThe thing.
The architect's role throughout the software delivery process is to keep the boundaries of requirements, model, and code clear and consistent. Looking back at the meaning of the entire software delivery is to meet the needs, so in essence, the boundary of the "requirements" determines everything, then the conclusion is self-evident:
The most important thing thatThe boundary (scope) of the requirement.
What is meant by clear boundaries
Say I have two requirements A and B, then we model the following outcomes, so let's feel which option you would normally give yourself as a result? And which option is the most desirable?
I believe that most people will agree that B and D are consistent with the principles of clear boundaries and consistency between requirements and model boundaries, while the reality is that most of the results are A and C. Various kinds of "joins" fill all corners of the system, and a typical example is the design of the user-role system.
With user-role systems, there are usually a few key requirements like these:
- Create User
- Create a character
- Setting up roles for users
- See what roles a user has
- See how many users a role contains
We did it in the most traditional design way, and the model looks roughly like this:
Doesn't this result correspond to the previous options A and C? Because of the existence of the "user aggregation" and "role aggregation" connection, the boundary between the requirements and the model is not consistent.
And what we're trying to do is eliminate the boundary-breaking connectivity while meeting all the needs.
How it works
First let's analyze the above diagram, if we remove the following requirements first:
- Setting up roles for users
- See what roles a user has
- See how many users a role contains
Then we will get a design that conforms to the principle of well-defined boundaries:
Then we think about which aggregation should be responsible for the following two requirements.
- Setting up roles for users
- See what roles a user has
The answer is obviously "user aggregation", so we can get the following design:
At this point you may wonder how to set which roles a user has if there is no connection between "User Aggregation" and "Role Aggregation".
The crux of the matterHere, usually we always put the "relationship table" in the diagram with a line, so if I say that the "user aggregation" has a set of attributes called "user roles", would you agree? Would you agree? If we know that a user object has an aggregate attribute called "User Role", wouldn't the above diagram make sense?
If we follow this idea and look at the requirement "see how many users are in a role", which model should solve it? I think you already know the answer, it's "User Aggregation", and we end up with the following design:
At this point, all the needs can be satisfied and the needs are divided into two ranges corresponding to the two models.
Why it's hard
If you have been following my thoughts and completed the above process, then you will realize that the boundary of the need does not exist objectively, but is our subjective delineation, and the purpose of this delineation is to be able to solve the problem within a defined range. Because it is subjective, it is not measurable or judgmental, and everyone can have their own thoughts on the division. In addition, it is simple because you can divide the boundary like the picture above and give the corresponding model to solve it, just as simple as assigning an organizer to your socks at home.
So often I sigh about domain-driven design:
The hard part about saying it's hard is making the trade-offs.
I say it's simple because I can clearly know what to take and what to leave.