Casey Charlton is writing a sample application using DDD. His first step was to create a UI mock-up to reflect a user story 
“What’s so bad about that?” I hear you cry. Well, here’s the problem:
UI prototyping is great for defining how a person is going to solve a business problem. It’s not great at defining what the problem actually is (i.e. the business domain).
I’ve seen this happen many, many times:
- Developer sketches UI, to start discussions with the Domain Expert/Business Analyst
- Business Analyst adds/removes/repositions some widgets
- ‘Hand waving’ and ‘pointing at imaginary boxes’ becomes the communication technique of choice
- Developer agrees to ‘quickly code up’ an interactive prototype
- End user wants a different shade of blue
Although the Developer has good intentions of leveraging DDD, the urge to see working apps overrides everything else – leaving the Developer with a vague understanding of the business domain.
As the Developer does learn more about the domain, he usually finds that the original UI design is inadequate. And changing a UI is expensive (it’s a pity that most businesses don’t understand why).
This is where TrueView shines. It automatically creates interactive UIs, but only based on domain definitions and relationships. Which means:
- The Business Analyst must describe the business domain.
- The Developer must start understanding the domain
- Both must define and share the Ubiquitous Language.
TrueView doesn’t give you a totally customisable UI, but you do get an interactive prototype that models the business. Once you understand the domain model, you’re in a perfect position to design a slick UI.