> My experience of Domain-Driven Design has been that it is extremely effective for driving conversations about the domain throughout the product life-cycle, but it produces frustrating codebases that are poorly attuned to the world outside the running process.
The DDD blue book by Eric Evans consists of two parts: Strategic Design and Tactical Patters. Is it accurate to summarize your comment as that the strategic design works very well, but that most of the information out there leads one to then learn about the tactical patterns in a particular OOP contexts, which isn't a universal approach, and in many cases shouldn't be the way to elaborate findings from Strategic Design?
Note that searching the web for "DDD" yields mostly OOP-related tactical patterns guidance, and this is why I think many people are so sceptical about DDD. It is the strategic parts where most of the (low-hanging fruit) value is.
Other non-OOP 'tactical' guidance, such as functional / functional-reactive / actor-driven, etc. DDD is harder to come by.
In my copy of the blue book, "Strategic Design" is Part IV, and there is no "Tactical Patterns" part or chapter. To be honest, I've only quickly read through Part IV, cherry-picking a couple of concepts, because it concentrates on techniques for dealing with very large domain models and/or very large organizations.
I think the good and bad are interleaved together throughout the book. Part I Chapter 2, "Communication and the Use of Language," is the one chapter I wish everybody I work with would read and digest. I think establishing a consistent language about the domain that is shared across functional groups is critical, so the domain terminology used in source code and comments is consistent with the terminology engineers use when talking with product and customer support. Part I Chapter 3 contains the clearest statement of (what I think is) the core error: "Tightly relating the code to an underlying model [which context makes clear is the domain model] gives the code meaning and makes the model relevant." The rest of the book is like that for me, alternating between vigorously nodding my head and yelling "WHY WOULD YOU TELL PEOPLE THAT," sometimes within the same chapter.
I suspect overall there's a communication issue with the book, where he focuses entirely on the themes of DDD and only occasionally gives lip service to other aspects of design. For example, when he says that module names and structures should reflect domain concepts, I think, "Yeah, that's really nice to the extent you can accomplish that, but you also want your module names and structures to reflect the logical structure of your program, so somebody can look at it and see how it works." You have these two aspects that should ideally both be legible in the code, but the DDD book doesn't show much respect for competing design priorities. In fact, it often warns against the dangers of being led astray by other design perspectives, such as architectural ones. Like so many other OO methodologies, the overwhelming thrust of the book is that if you attend to what it's teaching you, everything else will take care of itself.
A priest once told me, a good priest will tell you when you need a lawyer, a good lawyer will tell you when you need a therapist, a good therapist will tell you when you need a doctor, and a good doctor will tell you when you need a priest. Be careful with an expert who always tells you that their expert perspective is what you need. The DDD book is definitely that kind of expert you have to be careful with.
The DDD blue book by Eric Evans consists of two parts: Strategic Design and Tactical Patters. Is it accurate to summarize your comment as that the strategic design works very well, but that most of the information out there leads one to then learn about the tactical patterns in a particular OOP contexts, which isn't a universal approach, and in many cases shouldn't be the way to elaborate findings from Strategic Design?
Note that searching the web for "DDD" yields mostly OOP-related tactical patterns guidance, and this is why I think many people are so sceptical about DDD. It is the strategic parts where most of the (low-hanging fruit) value is.
Other non-OOP 'tactical' guidance, such as functional / functional-reactive / actor-driven, etc. DDD is harder to come by.