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

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