I'm taking on a new client for my consulting business and I'm reiterating the need for close working on domain understanding, and therefore domain driven design.<p>I like the principles but not the details and was wondering if HN had any thoughts/tips when using (or not using) DDD?
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.<p>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.
I am also very interested to hear opinions on DDD.<p>I recently finished _Architecture Patterns with Python_ [0] which talks about DDD and it was very good. They show some examples of what it looks like to properly highlight and isolate the domain and that was immediately applicable in my work.<p>I am currently working through the Eric Evans book [1] which is a little more abstract and challenging. The intro really resonated with me: at the end of the day we are trying to solve domain problems so that needs to be core of your architecture. However I work on complex domain problems in finance with less attention to pure technical challenges (e.g. scaling) so I am not sure if the domain is equally important to others.<p>[0] <a href="https://www.goodreads.com/book/show/50083115-architecture-patterns-with-python" rel="nofollow">https://www.goodreads.com/book/show/50083115-architecture-pa...</a><p>[1] <a href="https://www.goodreads.com/book/show/179133.Domain_Driven_Design" rel="nofollow">https://www.goodreads.com/book/show/179133.Domain_Driven_Des...</a>
I think it's actually quite difficult to grasp. So first, most discussions on DDD are inaccurate because everyone has different understanding of it (ironically).<p>I do like the whole domain thing. I'm at a stage where we have a lot of discussion on architecture, because we expect architecture to solve the problem of separation of concerns. But the problem is mostly domain.