Domain Driven Design Chapter 3 Summary

Chapter 3: Binding Model and Implementation

• "The first thing I saw [...] was a complete class diagram [...] that covered a large wall. [...] As large as the wall size diagram was, the model did capture some knowledge. After a moderate amount of study, I learned quite a bit (though that learning was hard to direct [...]). I was more troubled to find that my study gave no insight into the application's code and design. [...] Because the model was "correct", the result of extensive collaboration between technical analysts and business experts, the developers reached the conclusion that conceptually based objects could not be the foundation of their design. So they proceeded to develop an ad hoc design."
• "The project had a domain model, but what good is a model on paper unless it directly aids the development of running software? [...] Domain-driven design calls for a model that doesn't just aid early analysis but is the very foundation of the design."
• Model-Driven Design
• "Tightly relating the code to an underlying model gives the code meaning and makes the model relevant."
• An analysis model, a model meant for understanding only and where mixing in implementation concerns is considered bad practice, fails to accomplish its goals:
• It is not created with design issues in mind, and is impractical for those needs.
• While some knowledge crunching happens, it is lost when coding begins.
• It will go into depth about some irrelevant subjects, while it overlooks some important subjects.
• Discoveries always emerge during the design/implementation effort.
• "Model-Driven Design discards the dichotomy of analysis model and design to search out a single model that serves both purposes."
• To make the model relevant:
• Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious.
• Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain.
• Demand a single model that serves both purposes well, in addition to supporting a robust Ubiquitous Language.
• Draw from the model the terminology used in the design and the basic assignment of responsibilities.
• The code becomes an expression of the model, so a change to the code may be a change to the model. Its effect must ripple through the rest of the project's activities accordingly.
• To tie the implementation slavishly to a model usually requires software development tools and languages that support a modeling paradigm, such as object-oriented programming.
• Modeling Paradigms and Tool Support
• "Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs. [...] Although many developers benefit from just applying the technical capabilities of objects to organize program code, the real breakthrough of object design comes when code expresses concepts of a model."
• Example: From Procedural to Model Driven
• The example discusses the use of a PCB layout tool, and how it will try to find the optimal paths for PCB nets. But the software does not support the concept of buses, which are groupings of nets that follow the same path, essentially connecting multiple pins between two components. Procedural code has been written to process the layout tool's data files and use a naming convention to define buses, but what this code can do is limited and messy, because of it's procedural nature. By using an object oriented paradigm, much more powerful and flexible concepts are able to emerge.
• Letting the Bones Show: Why Models Matter to Users
• "In theory, perhaps, you could present a user with any view of a system, regardless of what lies beneath. But in practice, a mismatch causes confusion at best -- bugs at worst."
• Microsoft Internet Explorer Favorites Example:
• "A user of Internet Explorer thinks of "Favorites" as a list of names of Web sites that persist from session to session. But the implementation treats a Favorite as a file containing a URL, and whose filename is put in the Favorites list. That's a problem if the Web page title contains characters that are illegal in Windows filenames. Suppose a user tries to store a Favorite and types the following name for it: "Laziness: The Secret to Happiness". An error message will say: "A filename cannot contain any of the following characters: \/:*?"<>|". What filename? On the other hand, if the Web page title already contains an illegal character, Internet Explorer will just quietly strip it out. The loss of data may be benign in this case, but not what the user would have expected. Quietly changing data is completely unacceptable in most applications."
• Either expose the fact that Favorites are just a collection of shortcut files, and let users leverage what they know about the file system to their benefit, or store the Favorites in a different way, so that they can be subject to their own rules, which rules would presumably be the naming rules that apply to Web pages. Either option would provide a single model that tells the user everything that he needs to know.
• Hands-On Modelers
• "Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design: less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason == software development is all design."
• "If the people who write the code do not feel responsible for the model, or don't understand how to make the model work for an application, then the model has nothing to do with the software. If developers don't realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of Model-Driven Design -- that the model supports an effective implementation and abstracts key domain knowledge -- is half-gone, and the resulting models will be impractical. Finally, the knowledge and skills of experienced designers won't be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a Model-Driven Design."
• "Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the Ubiquitous Language."