4 ms·

> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is

by rewma 5y ago

> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs between complexity and correctness. As DDD comes up sounding like too much work to implement too much complexity that brings too little value, they flag it as a concern. What I believe is missing from this discussion is the scenario where DDD practices are not followed and consequently teams are forced to iterate and reimplements projects or parts of it just to fit requirements that emerged because some aspects of the domain model weren't looked into. Design by accretion is largely accepted, as is technical debt, but they do have a cost.

oscarcp 5y ago
You make quite the point here. That is the advantage I see for DDD; you have dependency on service that may change, DDD will make your life easier when switching, otherwise there will be weeks of rewriting code. And what happens during transition times (thinking about CRM for example) where you have to keep connected to both systems?. This said, in my situation it's like trying to kill flies with a muon cannon (fyi. this gun is fictional and it's exaggerated to drive the point), it's cool'n's*it but the same could have been done with a newspaper or your hand. To maintain the muon cannon you need the entire Fermilab team, your hand... well, it's your hand. Apologies for the exaggeration, can't avoid it :D
pydry 5y ago
>I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models Every text I've ever written on DDD has made it pretty clear that these patterns are at the very heart of what it is. I've never seen one that says "look, all this stuff is optional, write your software however, here's how to really get to grips with the domain model". I don't think it's the critics conflating. It is what it is.

by rewma 5y ago

oscarcp 5y ago

You make quite the point here. That is the advantage I see for DDD; you have dependency on service that may change, DDD will make your life easier when switching, otherwise there will be weeks of rewriting code. And what happens during transition times (thinking about CRM for example) where you have to keep connected to both systems?. This said, in my situation it's like trying to kill flies with a muon cannon (fyi. this gun is fictional and it's exaggerated to drive the point), it's cool'n's*it but the same could have been done with a newspaper or your hand. To maintain the muon cannon you need the entire Fermilab team, your hand... well, it's your hand. Apologies for the exaggeration, can't avoid it :D

pydry 5y ago

>I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models Every text I've ever written on DDD has made it pretty clear that these patterns are at the very heart of what it is. I've never seen one that says "look, all this stuff is optional, write your software however, here's how to really get to grips with the domain model". I don't think it's the critics conflating. It is what it is.