3 ms·

DDD is one of the most misunderstood "patterns" I've encountered. I started my career in the late 00s, and Evans' DDD/Fowler's PoEAA were treated by gospel as s

by mjr00 2y ago

DDD is one of the most misunderstood "patterns" I've encountered. I started my career in the late 00s, and Evans' DDD/Fowler's PoEAA were treated by gospel as some, and I couldn't quite understand why. With years of experience, I now get it: software being built in 2003 was a lot different than software today. DDD/PoEAA implicitly are about building long-lived, stateful thick clients -- i.e. a Java/C++ desktop application, because that's what people built by default in 2003. In the past 22 years, things have changed. The Bezos "API mandate" has either explicitly or implicitly been adopted by many organizations. Front-ends are much more likely to be websites/Chromium operating with stateless HTTP requests, instead of long-lived desktop applications. (React has "won" as the default JS framework over the past 10 years, and that has its own set of architectural patterns which don't mesh with DDD.) Backend software is built with a cloud-first mentality: servers can fall over at any minute, the application should scale up by adding more servers, etc... All this leads to a much different approach. Statelessness is nonnegotiable, since you're dealing with stateless HTTP/GRPC requests that expose most or all of your functionality. The "anemic domain model"[0] is derided as an antipattern by DDD, yet it's the most sensible approach for dealing with objects that get loaded and disposed of with every request. Complex ORM schemes and patterns like "unit of work" are fine when dealing with small amounts of data, but break down when you start needing to care about e.g. splitting transactions into smaller chunks because writing 200,000 rows in a single tx is a bad idea. I don't think DDD is useless, but its application is much narrower than advertised. It's a shame that even today people are still being taught from DDD as if it's the "right" way to code when for a large amount of modern software it's a terrible fit. [0] https://en.wikipedia.org/wiki/Anemic_domain_model https://en.wikipedia.org/wiki/Anemic_domain_model

dvydra2 2y ago
Well said! Designing from first principles is how we get ahead and outcompete those who are stuck in the past.
globular-toast 2y ago
So are you saying nobody needs to write "small amounts of data" any more and we should treat everything like it's a 200k row write? I don't get how an an anaemic data model makes more sense just because of database persistence. You save/load the data. It's completely irrelevant where the logic is.
- mjr00 2y ago
  > So are you saying nobody needs to write "small amounts of data" any more and we should treat everything like it's a 200k row write? Not at all. As I say, DDD isn't totally inapplicable now; if you're writing a small, stateful application with no need to expose functionality externally, it can be a good fit. But you're a lot more likely to be dealing with data volumes that require 200k row transactions, or a requirement to expose functionality and data via APIs, in 2024 than you were in 2003. The scale of software has gone up significantly in 20 years. > I don't get how an an anaemic data model makes more sense just because of database persistence. You save/load the data. It's completely irrelevant where the logic is. DDD largely treats the database as an impure, imperfect implementation detail that needs to be worked around, rather than an essential part of the application. I've seen examples of creating "entities" called like `UserTransaction` in order to retain the "purity" of using OOP for everything. There's also a lot of literature where people suggest using database CASCADE to deal with updates/deletions which, IMO, is awful and outdated. It's totally ridiculous and is just creating more work in order to avoid the bogeyman of (gasp) stateless procedural programming that was very out of fashion at the time DDD was written.
  - globular-toast 2y ago
    > if you're writing a small, stateful application with no need to expose functionality externally, it can be a good fit. Small in what way? For me a "large" application is one with many business rules, not one with many rows in the database. So I would have said DDD was more suitable for the "large" application, not the small one. Yeah, it's more likely that people will write software to handle large amounts of data, but that data has to come from somewhere. Somewhere there must still be software that makes small transactional changes according to business rules. But perhaps this is what you meant by the "small stateless application". The main thing for me is that it should be possible to write business rules in some language that isn't SQL, because SQL only supports CRUD. This idea is espoused by SICP, Clean Architecture, DDD etc. Using something like DDD is beneficial only because other developers already know the concepts like repository etc. But it could be anything that works.

by mjr00 2y ago

dvydra2 2y ago

Well said! Designing from first principles is how we get ahead and outcompete those who are stuck in the past.

globular-toast 2y ago

So are you saying nobody needs to write "small amounts of data" any more and we should treat everything like it's a 200k row write? I don't get how an an anaemic data model makes more sense just because of database persistence. You save/load the data. It's completely irrelevant where the logic is.

mjr00 2y ago
> So are you saying nobody needs to write "small amounts of data" any more and we should treat everything like it's a 200k row write? Not at all. As I say, DDD isn't totally inapplicable now; if you're writing a small, stateful application with no need to expose functionality externally, it can be a good fit. But you're a lot more likely to be dealing with data volumes that require 200k row transactions, or a requirement to expose functionality and data via APIs, in 2024 than you were in 2003. The scale of software has gone up significantly in 20 years. > I don't get how an an anaemic data model makes more sense just because of database persistence. You save/load the data. It's completely irrelevant where the logic is. DDD largely treats the database as an impure, imperfect implementation detail that needs to be worked around, rather than an essential part of the application. I've seen examples of creating "entities" called like `UserTransaction` in order to retain the "purity" of using OOP for everything. There's also a lot of literature where people suggest using database CASCADE to deal with updates/deletions which, IMO, is awful and outdated. It's totally ridiculous and is just creating more work in order to avoid the bogeyman of (gasp) stateless procedural programming that was very out of fashion at the time DDD was written.
- globular-toast 2y ago
  > if you're writing a small, stateful application with no need to expose functionality externally, it can be a good fit. Small in what way? For me a "large" application is one with many business rules, not one with many rows in the database. So I would have said DDD was more suitable for the "large" application, not the small one. Yeah, it's more likely that people will write software to handle large amounts of data, but that data has to come from somewhere. Somewhere there must still be software that makes small transactional changes according to business rules. But perhaps this is what you meant by the "small stateless application". The main thing for me is that it should be possible to write business rules in some language that isn't SQL, because SQL only supports CRUD. This idea is espoused by SICP, Clean Architecture, DDD etc. Using something like DDD is beneficial only because other developers already know the concepts like repository etc. But it could be anything that works.