This instrument follows on from the previousTo land DDD for Javaer, we had to write open source components", welcome to pay attention to the public number (Lao Xiao wants to be a foreign language big brother), get the latest article updates and DDD framework source code, video and live in B station.
/s/Nsc3hwl4u9je7DaXsC05mg
contexts
We introduced a modeling process of "user-role" in the article "This is the hardest part of DDD modeling (in fact, it's very simple)", and when we discussed the topic of "how to analyze the business and modeling in order to meet the requirements under the premise of the requirements and model boundaries are clear and consistent! When we discuss the topic of "how to analyze the business and modeling to make the boundaries of requirements and models clear and consistent under the premise of requirements", we find that many experienced developers will always bring all kinds of concerns and doubts, "how to deal with table relationships in the database", "can't we solve the problem with correlation query?", "why can't we have correlation query? "Why can't we have a correlation query?" "Since there is a so-and-so Id, it means that they have a relationship, why do you say that the boundary is clear?" Why do you say that the boundary is clear?".
I wondered what the problem was here, and why the ideas we take for granted are still confusing to many people, and after a deeper discussion with our teammates, I think we've found the problem.
The Curse of Knowledge
I remember a scene in "The Legend of Yitian Dragon Slayer" where Zhang Sanfeng teaches Zhang Wuji the Taiji Sword Technique, and after teaching him, he asks Zhang Wuji several times, "How much of it do you still remember?" After teaching him, Zhang Wuji asked several times, "How much do you remember?", and Zhang Wuji finally said, "I've already forgotten all of them." Zhang San Feng was very happy: "Good, you can go on."
Going back to our software design scenarios, our experienced engineers, who are always thoughtful, will consider whether there is enough performance? How will the model be stored in the table? Does the table structure make sense? Should there be one-to-one relationships or one-to-many? Or should it be many-to-many? This series of questions makes it impossible to concentrate on what the nature of the business is, and prematurely focus on the technology, and your mind is full of how to write SQL statements when you are warmly communicating with business experts about customer scenarios.
I think that's probablyThe Curse of KnowledgeBarring that, carrying a heavy burden on the mind, the odds are that you can't make a more accurate judgment either.
Forget the database.
Now assuming that the technology has advanced to a very top level, we have the following capabilities:
- The application has unlimited memory;
- Application memory is never lost;
So, do we still need a database? I don't think so, what would our code look like? Wouldn't it be enough to construct an instance of the model in memory to add to its collection container?
If you don't need a database anymore, can you forget about the database when modeling and just think of the model as individual instances of a type? Would your modeling mindset change? In this context, let's revisit the concept of "domain boundaries".
Suppose we still use the guidelines mentioned in the previous post:"There are no cross-references between aggregates", then wouldn't the result of your design look like what we deduced earlier, like the following figure:
If you're still confused, I'll add the specific class diagrams as well, so you won't be able to see at a glance:
return to reality
Of course, the reality is that our technology is not as developed as envisioned above, we ultimately have to store the model data to the database, therefore, we need ORM framework to help us solve the model "access" problem, note that I used here is "Access ", does not include search, search things, we can use a more flexible solution, which involves a pattern called CQRS, which is another story.
If we have a very powerful ORM that can help us take out the model based on the Id, and after we manipulate the model, the ORM "Saves" it into the database for us, and we don't need to care about what it actually does, then is it possible that this ORM can also help us get rid of the curse of "database knowledge" so that we can focus on the requirements and the model when modeling? So is it possible that this ORM can also help us get rid of the curse of "database knowledge", so that we can focus on requirements and models when modeling?
What's the conclusion?
Based on the above derivation, I think there is a conclusion as follows:
- Database knowledge that can become a mental burden when analyzing requirements and modeling;
- A powerful ORM that helps engineers get rid of the mental burden of "database knowledge";
- When analyzing requirements, you only need to be concerned with the requirements and the model;
So, what do you think about the conclusions above? What kind of ORM are you using, and is the code organized in a way that allows you to focus on the business for the projects you're involved in? Feel free to have a friendly discussion in the comments section of the article, and also feel free to follow my public number (Old Xiao Wants to be a Foreign Language Big Brother) to get the latest updates.
(dialect) remarry
In the next post, I'm going to introduce a modeling communication method that builds empathy across personas to make our modeling thinking landable and replicable, so stay tuned.