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.
Gojko Adzic has an interesting piece by Eric Evans about replacing legacy systems.
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.
Here are some tips for DDD newbies. It’s easy to fall back to doing ‘what you know best’, so use these tips to stay focused. Hopefully your design skills will get better (and faster) as a result. 
- Don’t start with the User Interface
Instead of asking “How will the user solve this problem?“, ask “What is the problem?“
- Design Domain Models, not database schemas
Most business users don’t understand database schemas – so don’t make them
- Design your Domain Model incrementally
Defining too much detail early on is the fastest way to get side-tracked
- Get constant feedback from your Domain Experts
Take advantage of TrueView’s auto-generated prototypes to get instant feedback
- Separate business concerns from technical concerns
Writing technical infrastructure code can be counter-productive during the modelling phase
- Unit testing wisely
Focus on testing non-trivial behaviour and complex business logic, possibly using BDD
- Think agile, be agile
Your clients don’t have time to wait, so don’t make them
You can read the detailed version here.