Ask HN: What do you think about Domain Driven Design? | Hacker News Reader

Ask HN: What do you think about Domain Driven Design?

13 pointswhiskey1411 comments

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.

I like the principles but not the details and was wondering if HN had any thoughts/tips when using (or not using) DDD?

View on HN

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.

These are exactly my thoughts:

> intuitive sense of those concepts and thus put off by what appears to be an overly formal treatise on obvious principles

I do however feel like there it would be helpful for junior/mid engs if there were a stripped down version of the blue book which defines vocab, obvious principle as you say, as general guidance for domain analysis/modelling

I am also very interested to hear opinions on DDD.

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.

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.

[0] https://www.goodreads.com/book/show/50083115-architecture-pa...

[1] https://www.goodreads.com/book/show/179133.Domain_Driven_Des...

I actually went in the opposite path to you. First reading the blue book, and then reading (and implementing Architecture Patterns in Python).

I really liked APwP but I found that it did over complicate matters.

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).

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.

That's my biggest takeaway as well. Which is, as a cross functional team, the thing we should be talking the most about it is the domain. Not components in other layers as they are generally team specific

I think DDD is a way of minimizing the semantic distance between the code and the slice of the world it affects.

> I like the principles but not the details

Could you be more specific about what details you don't like?

What I like about the principles: - ubiquitous language, close working between eng/experts

What I don't like about the details: - categorising things as aggregates, entities, value objects, context boundaries

I understand why it might help to classify certain things but I also feel that some things don't fit well in that framework. For example, you might have an entity that is core between two aggregates and sits as bridge object e.g. at an edtech app, an exam instance (a sitting) would sit between two separate aggregates of (exam) and (products/store/ecommerce)

wow I've never heard any of those terms. Sounds like philosophy to me. What I would say is dont take any one general rule gospel. Exercise common sense.

Sorry for the waffle...those terms are all from the DDD blue book.

Agreed with the common sense. I guess that I just find it a bit lacking that such a core skill for engs is glossed over as common sense, when it might be helpful for junior/mid engs to have this on their radar that they should be thinking deeply about. And therefore techniques or guidance on how to do it well

Reply on news.ycombinator.com