One of the topics that caught my attention was Exploration and Experimentation (3m 25s into the video).  Evans suggests that teams should be exploring & experimenting even after a useful domain model is created.  His quote:

What are the odds that [the first good model] is the best you could have done?

So why aren’t teams doing this already?  Typically, it’s because of fear and cost of change. Traditionally, software has never been easy to change (read expensive).  And for all of the new technology being spewed out, not all of it is designed to make change easy.

This is the void that TrueView attempts to address.  It’s not about UI design, or database design, or Web Service contracts.  It’s about creating interactive domain models that Domain Experts and Software Experts can explore, discuss, and help refine the ubiquitous language.

If you haven’t tried it already, you can download it here. I hope you find it useful.

“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.