Someone asked a very important question over at StackOverflow. The answer is also crucially important:
“Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it’s very easy for your head to fill up with ORMs, MVC frameworks, AJAX, SQL vs NoSql, … So much so there’s little space left for the actual problem you’re trying to solve.
And that’s DDD’s key message: don’t. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.”
Of course, I had to give this answer my vote too…
Eric Evans talks about the most essential parts of his book, having practiced it over the last 5 years.
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.
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.