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:

1. Developer sketches UI, to start discussions with the Domain Expert/Business Analyst
2. Business Analyst adds/removes/repositions some widgets
3. ‘Hand waving’ and ‘pointing at imaginary boxes’ becomes the communication technique of choice
4. Developer agrees to ‘quickly code up’ an interactive prototype
5. 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.