The thing with DDD is that most ideas it expresses are not unprecedented. Most good programmers will tend to have an intuitive sense of those concepts and thus

The thing with DDD is that most ideas it expresses are not unprecedented. Most good programmers will tend to have an intuitive sense of those concepts and thus put off by what appears to be an overly formal treatise on obvious principles. I don't see it as any practice or process that can be adopted by a team, rather my takeaway from the book was the emphasis on domain, and the need to develop a common vocabulary that can help communicate about the domain. Building a vocabulary in itself is not going to solve design. The hardest parts are always in agreeing to what the right domain is, and the book makes it no secret that there is no silver bullet, but that it is a hard, continuous pursuit. I think ultimately the greatest value the book has to offer is to provide a window into the minds of wise old men, to understand their thought processes honed over long accomplished careers, learn from their mistakes and experiences and build mental tools of our own that can help us think in the same direction.