9.3. Motivation: Why Create a Domain Model?
I'll share a story that I've experienced many times in OO consulting and coaching. In the early 1990s I was working with a group developing a funeral services business system in Smalltalk, in Vancouver (you should see the domain model!). Now, I knew almost nothing about this business, so one reason to create a domain model was so that I could start to understand their key concepts and vocabulary.We also wanted to create a domain layer of Smalltalk objects representing business objects and logic. So, we spent perhaps one hour sketching a UML-ish (actually OMT-ish, whose notation inspired UML) domain model, not worrying about software, but simply identifying the key terms. Then, those terms we sketched in the domain model, such as Service (like flowers in the funeral room, or playing "You Can't Always Get What You Want"), were also used as the names of key software classes in our domain layer implemented in Smalltalk.domain layer p. 206 This similarity of naming between the domain model and the domain layer (a real "service" and a Smalltalk Service ) supported a lower gap between the software representation and our mental model of the domain.
Motivation: Lower Representational Gap with OO Modeling
This is a key idea in OO: Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities. Figure 9.6 illustrates the idea. This supports a low representational gap between our mental and software models. And that's not just a philosophical nicetyit has a practical time-and-money impact. For example, here's a source-code payroll program written in 1953:1000010101000111101010101010001010101010101111010101 …
Figure 9.6. Lower representational gap with OO modeling.
[View full size image]