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…

But I’m seeing a lot missing from the discussions.  Like “What about the locking implications around an Aggregate?” or “Must Value Objects be immutable“, or even “How do entities retrieve data if they can’t access a repository?“.

To that end, I’ve created a set of interfaces and base classes that represent the building blocks of DDD.  The idea is to get developers thinking about key concepts early in the design process, and let Intellisense provide some guidance.

You can download the source code here.  It has a Ms-Pl licence, so you can modify and use the code as you wish.

The DDD related interfaces are:

• IDomainObject
• IEntity
• IAggregateRoot
• IValueObject
• IList<T>
• IFactory<T>
• IRepository<T>
• IService<T>
• ISpecification<T>
• IQuerySpecification<TRequestor, TResult>

Additional interfaces for orthogonal concerns are:

• IPersistable
• IPersistableList<T>
• IAudit
• IAggregateLock
• IAssertion
• IDependencyAware
• IDependencyLocator
• ITrackable

This is still a work-in-progress, so feedback would be greatly appreciated.  In the next couple of posts, I’ll describe the interfaces and classes.

Download the C# project

P.S. The next version of TrueView will be based on these interfaces.  So if you code a domain model using the compiled library, TrueView will auto-generate a completely interactive UI (with the appropriate semantics) directly from your model.

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.

In summary, focus on the core domain – the part of the software that brings competitive advantage to the business – and use an anti-corruption layer to interface with the old system.

1. Don’t start with the User Interface
   Instead of asking “How will the user solve this problem?“, ask “What is the problem?“
2. Design Domain Models, not database schemas
   Most business users don’t understand database schemas – so don’t make them
3. Design your Domain Model incrementally
   Defining too much detail early on is the fastest way to get side-tracked
4. Get constant feedback from your Domain Experts
   Take advantage of TrueView’s auto-generated prototypes to get instant feedback
5. Separate business concerns from technical concerns
   Writing technical infrastructure code can be counter-productive during the modelling phase
6. Unit testing wisely
   Focus on testing non-trivial behaviour and complex business logic, possibly using BDD
7. Think agile, be agile
   Your clients don’t have time to wait, so don’t make them

You can read the detailed version here.