I started reading Implementing Domain Driven Design recently. I am happy there is a new DDD book. Even though I have read the original book multiple times I still feel like I am messing up some of the most important concepts. Vernon mentions in his new book that many people feel the way I do and he names our level of DDD practice "DDD-Lite". I am hoping reading his book will help me transition to a deeper level of understanding of DDD. If I learn something I find interesting I will try to post it here. Below is my first submission.
In Chapter 1, Vernon suggests that your domain expert should be able to read your first test that you create to define the new behavior you are adding to your domain model. I like this idea, because I think it will give you a good way to measure whether you really are creating a ubiquitous language and using it to design your code. If the domain expert can't understand your first test then your code is probably too complicated and you may not be getting the full benefit of DDD.
At work we create XML based tests that get translated into code. Part of the reason for creating the XML based tests was so our domain experts could read them. I think I like Vernon's solution better to this problem though. I like his solution better because our XML based solution allows us to write domain code that doesn't match the domain experts understanding of the problem and still show them domain tests that makes them think we understand the problem. The XML based solution is kind of like a cheat that covers up the real problem that our domain code is too complicated.