Again, it’s important to remember that the model should not model real life. If not, we can keep them simple by using uni-directional associations or adding a qualifier. Associations tend to add complexity, so the author recommends on removing association if possible. One well-known way to do this is to use a layered architecture. This way, you decouple the domain from other concerns like UI or infrastructure. First, it emphasizes the importance of isolating the domain. The second part of the book delves into the Building Blocks of a Model-Driven Design.
The Building Blocks of a Model-Driven Design This can flesh out inconsistencies in code and make implicit concepts explicit.
#DOMAIN DRIVEN DESIGN BOOK CODE#
Its purpose is to remove any translation between the analysis model and the code model. You should use it everywhere: code, discussions and tests. Also, this section introduces the concept of the Ubiquitous Language. As you add more use cases and you gain more knowledge, you should refine and improve the model. Its only purpose is to solve the current use cases. The model of a domain doesn’t need to be realistic. In the first part, Putting the Domain Model to Work, the author talks about the importance of domain knowledge. The book has four parts: Putting the Domain Model to Work, The Building Blocks of a Model-Driven Design, Refactoring Toward Deeper Insight and Strategic Design. The main purpose was to gain more knowledge about the strategic patterns of DDD. So, in order to get a better understanding about what is Domain-Driven Design, I decided to read the book that introduced it. Even Eric Evans says that he has overemphasized the building blocks. Six years later and I still see people paying more attention to the tactical patterns. I kind of got the idea behind repositories, entities, value objects, etc. Being a junior, I gave more attention to the tactical patterns. When I started programming, people were talking about Domain-Driven Design.
0 kommentar(er)
