One way to maintain conceptual integrity is to apply the Domain Pattern. Two good resources covering Domain Driven Design (DDD) are:
• Domain Driven Design, Eric Evans 2004
• Applying Domain-Driven Design and Patterns, Jimmy Nilsson 2006
An application’s conceptual language takes centre stage in DDD, allowing business owners and developers to talk the same language. A clear, simple conceptual language shortens the divide between business analysts and developers, during their feature discovery cycles.
I can’t stress enough: Good software is all about good communication. Agreement between project stakeholders, to work toward a simple conceptual language modelling real-world processes will improve the project's chances of success.
Maximise understandability by minimising overloaded meaning.
If there is more than one word or phrase to describe a process, try one of the following:
- Look for a more specific word, that narrows meaning. "Entity" is a pet hate of mine. Seriously, unless accompanied by a domain specific context, get rid of it. Substitute it for "Thingy" - at least it will scream attention as you increase domain fidelity.
- Agree to use one word and actively ensure all conversation participants support the decision. This decision should come from the business owners.
- When neither word suitably describes the overloaded meaning, the issue is usually one of context. Extract the contextual meanings and distill into one description for each context. Agree on a single abstract word for the original overloaded word. The abstracted word and one of the context descriptors will then be used to narrow meaning in the domain.
Step 12 in “The Joel Test”, which documents 12 steps to better code, asks if you do hallway usability testing. I feel this testing is really challenging your Domain Model using your conceptual language.
Continually test your domain model's power, flexibility, complexity and conceptual integrity:
- Can it answer a question required for your next iteration?
- Is the answer way to complex or a little vague?
- Are there several ways to answer the question, and if so, is it an early indicator of a domain model or conceptual language smell?
This is my way of hallway testing…as a spontaneous design session. Don't be afraid to put your domain model, or parts of it, on the wall for all to see. Put post-it notes on the model with questions you expect the model to answer (i.e. Can user x searh all assets owned by business unit y?). Encourage others to comment, question and amend through this shared process.
Remember, the more "cold" eyes on a problem area, the better chances that problem has of being resolved properly.
