Creating Good Domain ModelsSource: firstname.lastname@example.org
Problem: How do you create good domain models?
Paul Oldfield wrote:
Building good domain models is a bit of an art. As for the others, you start off, and get good with practice. Any feedback you can get as you go along will be useful - particularly if you can get advice from those who are already good. Failing this, try having someone else covering the same area independently, and try justifying the resulting differences to each other.
There are a whole host of techniques for OOA out there. Of these, I find Rebecca Wirfs-Brock's CRC cards the most helpful. However, the real work of a good domain analyst is done as he is talking to the domain expert, and eliciting the domain knowledge. Typically, he will be sketching out the domain model as he goes. [...]
Robert C. Martin replied:
One can sometimes get caught up in the act of building a model, and forget what the goal is. You don't need to understand how to build "good" domain models. Rather, you need to tools and techniques for building an understanding of a domain. Building models can be a great help; but building models is just one means to the end. Moreover, building models is not sufficient to gain the necessary understanding. There are other things you have to do.
Above all, you must communicate with the experts in the domain. You must establish a rapport with them, and learn how to derive information from them that they themselves aren't aware that they know.
As for models, UML is a fine tool so long as you don't take it too seriously. Mathematical models are also quite useful; as are data flow models, storyboard models, use case models, etc, etc.
Among the quickest and best ways to ensure that you are communicating well with the domain experts, is to produce tiny bits of the system very early on. The domain experts can validate whether those system bits are appropriate or not; and they'll begin to learn about what you do as much as you learning about what they do. This strengthens the rapport between you. The more bits of the system you can show them, slowly growing into bigger and more elaborate bits of the system, the better. In the end, they can guide the development of the system by seeing release after release and telling you what's right and what's wrong.