Hacker News Reader

Comment by y4mi | Hacker News Reader

You clearly have some positive experience with DDD, and I'm definitely not trying to say that DDD is broken by design or anything like that.

I'm sure there are successful and maintainable projects that utilize this design approach.

Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still pretty convinced I'd rather implement it with less abstraction/indirection.

It might just be a difference of character at the end of the day, because I do agree that what you write sounds great. I just see it more like a triangle in the CAP theorem, where the edges are speed, abstraction/extensibility and stability/consistency

View on HN

> Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still pretty convinced I'd rather implement it with less abstraction/indirection.

This example clarifies the intent behind DDD: make the implicit explicit and make sure there is awareness about all the edge cases.

It might be as simple as contacting a user in case you have an uncovered edge case, but at least you'd be aware that your system is unable to handle edge case X. (In non-DDD scenarios this would just be a bug that emerges - implicit behavior.)

Yes! When the project becomes large enough, a lot of value loss can be prevented by discovering edge cases before implementation, and DDD practically forces that to happen. Less things discovered by devs means less design cycles, which means less effort lost in design and implementation—of course only as long as proper grooming is done to avoid implementing things out of customer priority.

This line of reasoning cuts both ways: how many bugs and inconsistent behaviors often pop up because developers rushed to write code without gathering enough requirements on the domain, how many productivity problems are caused by growing the system by accretion where it can, and how many rewrites were required just to fit the system's domain to the problem and shed technical debt from the accretion.

Reply on news.ycombinator.com