This instrument follows on from the previousThe Anti-DDD Pattern of "Reuse"", 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 was on the air recently, I saw a message asking if I had any articles on how to divide the field, and after looking through them, I found that there was no dedicated, serious and detailed talk about such an important issue. It is no wonder that many people say that they are not grounded and engage in some vain things all day long. But the reason for not speaking, I still have to defend myself a few words, not want to speak, not can not speak, but I subconsciously feel that the essence of the things to understand, this issue is too simple, there is no need to speak.
Of course, if you are an old fan of mine and have followed my past outputs, then you also know that earlier there was a DDD open class in our FireUG community dedicated to this topic ([DDD Domain Driven Design | PART V: How to Identify Domain Boundaries?/sRqAC8O ）。
To this day, my own perception of software engineering has gone through another round of iterations to reinterpret the question.
Let's start with the answer.
Q: How are the fields divided?
A: A field can be derived based on the following two articles:
-
When you have a requirement called create xxx, then that xxx is an aggregate root;
-
We can regard an aggregate root as a field;
How to interpret
For example, a system in which a user needs to be created, then a user is an aggregate root, a user is a domain, and so on and so forth are very easy to recognize, and I'm sure it's possible to make judgments based on this rule regardless of your software design experience.
Of course you will say, I have a need to create a shipping address for the user, so is this shipping address an aggregate root? This depends on whether you are creating a "shipping address" or a "user's shipping address", if you think it's a "shipping address" then it should be an aggregate root, if you think it's a "user's shipping address", it means that the requirement is only for a "user's shipping address". If you think it's "shipping address", then it should be the root of the aggregation, if you think it's "user's shipping address", it means that the requirement is just to add a new value to the "user's shipping address attribute".
Orders, for example, do you think of "Create Order" or "User's Order"? I think most people would intuitively choose "create order", why would they have such an intuition? I think you'll come up with the answer that "orders" is complex enough.
So does it seem that the criterion for understanding business has become the less measurable judgment of "separate the complex"? If you look at it the other way around, you will find the answer, which is "merge the simple ones".
Or the previous example, or shipping address, because there is a requirement called "create shipping address" or "create user's shipping address", I can't tell, it doesn't matter, we'll just default to the existence of this aggregate root, there is the field We'll just default to the root of this aggregation, that there's a field called "shipping address". Then we will consider whether it is beneficial for us to have this field on its own, and whether it is acceptable for us to merge this field into the "user" field. If we are confident that there is no problem with the merge, then we merge it, otherwise, we make it a domain and keep the boundaries clear.
Why is the judgment based on creating xxx
Maybe, you will have a question, why to judge the aggregation root based on the "create xxx" requirement? The core logic is that this type of requirement means that xxx is an indivisible whole, meaning that xxx is the smallest complete range, which is equivalent to this type of requirement, we identify the "atomic unit" within the system, like a piece of Lego, which can not be disassembled.
What's the essence?
It seems to me that the essence of the method of dividing the field in this way is that we first think that theThe border is right there., where there is a need to create XXX, i.e. a domain exists, it just means that we have thought about it and certain domains are merged in to make it more certain that the complexity is manageable, then we have made the decision to merge the domains.
So, rather than this being about how to divide the field, this is about thinking about when to merge fields.
Underpinning underlying values
If you've been following this series of articles all the way through, you'll know that my central point about software design is:
-
DDD is a value
-
Keeping boundaries clear is the most important thing
Then you'll see that the approach described above is fully consistent with this value, where we first identify the "atomic units" that make up the system, recognize them, and then carefully merge them, prioritizing keeping domain boundaries clear and avoiding coupling between them if we're not sure.
The basis for believing in this value is our understanding of complexity, which is also explained in detail in the previous section:
-
System complexity is related to the number of elements and the relationship of the elements;
-
The relationships of the elements have a much greater impact on the complexity of the system than the number of elements produces;
At the end of the day, the core purpose is still to maintain our control over the complexity of the system, so we are careful to "build coupling" between domains within the system.
Full instructions
So, if you're like me and agree that DDD is the value and that maintaining boundaries is the most important thing, our complete modus operandi is:
-
When you have a requirement called create xxx, then that xxx is an aggregate root;
-
We can regard an aggregate root as a field;
-
When we are very sure that we can control the complexity of a domain when it is merged, we can consider merging the two domains;
wind up
The above is the practical way our team analyzes requirements, designs solutions and models on a daily basis, if you agree or resonate with it, I also look forward to you sharing the article with more friends. If you hold different views and perspectives, you are also welcome to discuss with me, I believe that at leastContinuously improving developer happinessWe have a consensus on this direction.