Ask HN: What do you think about Domain Driven Design?
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?
11 comments
[ 3.4 ms ] story [ 40.9 ms ] threadI 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 really liked APwP but I found that it did over complicate matters.
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.
> 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
Could you be more specific about what details you don't like?
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)
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
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.