I found DDD very poorly written. It's a nightmare slog to read. I find Evans isn't a gifted writer and thinks unedited rambling is appropriate for a textbook. The 600 pages could easily have been 100. DDD can also be a poison to core systems, and Evans never considers this (I don't think he knows it). If you try to encode business domains, service lines, product names, stakeholder role names, what have you, into your core software, now you can't iterate on the business, because it requires refactoring the core. Building generic platforms with minimal "domain" (whatever that term means, Evans can't even define it) concerns in it, and keeping the business logic as far in user configuration land as possible, gives a business more flexibility and a better chance at surviving.
I don’t believe that Evans was arguing for pulling every concern in the wider system into a single model (the last third of the book gives techniques for overall system architecture). Different service lines, or products, would surely belong in distinct bounded contexts in DDD.
> keeping the business logic as far in user configuration land as possible
This sounds dreadfully difficult to build and test. The kind of business rules engine that you’re describing is more likely to be overpriced and buggy than a simpler well-modeled set of core domain classes imo.
I've only had one experience with DDD at an company that was very interested in it and trying to push it into their codebase, and kind of 'righteous' about it. Zealots in other words but unfortunately they didn't have enough real world experience to know what actually worked well in their context.. just cargo culting.
They had a project in planning for 18 months but hadn't been able to start it. I was hired as a principal and given this one of my major impacts to deliver, though other things kept getting piled on in front of it. To actually get it done one weekend I sat down and cranked out a functioning POC that could easily and rapidly be extend into the fully working system.
Come Monday they were blown away to see the major progress of an actual working system, and loved the system and were very happy about it. Then the bike-shedding began, an order of magnitude more person hours was spent talking about it than it took me to build it and they required rewriting it because they a data library I used 'old tech and uncool'..
Hilariously that data library was actually a DDD system that created bounded contexts and enforced a domain model in them, but due to their lack of understanding they didn't see that! The hilarious irony!
I wasn't a DDD guy, though having been a high level architect for 15 years I was using all the things I have found that worked best. Some time later I was reading about DDD and realised that system was actually DDD. Of course by that time I had already left, to deliver working systems instead of waste time bike-shedding with cargo culters!
I would love to know how many members of that team read the book cover-to-cover. I’m consistent surprised by how many developers invoke a particular methodology without having sone the work to understand it.
In particular, I’ve gone through very similar experiences where functional-programming was the silver bullet that secretly no one understood.
I am now in an organization that is cargo-culting DDD, and this serves well layers of middle management pretty much the same way as OpenAPU or asyncapi.
Anything which is not code gets used as a pretext to not do actual work.
I think a lot of people suggest Patterns, Principles, and Practises of Domain Driven Design instead.
The Evans book is sort of written backwards, in that it starts with a bunch of powerful tactical tools and people stop reading halfway through which means now all they have is a hammer.
The PPPoDDD book instead starts out with reasoning about when DDD is appropriate and when it's not, to dive into the tactical patterns last, once the other options are eliminated. I think that approach makes much more sense.
After all, most of the skill in a technique consists in knowing when to apply that technique, and, critically, when not to.
The PPPoDDD book also places a heavy emphasis on having productive conversations with businesspeople as a design tool. I think Evans accidentally underemphasises that too.
