I worked on a number of software projects with Eric and got a lot out of his book before that.
I'm sure you have good reasons for disliking DDD and I bet Eric would probably agree about most of them. This is what happens when ideas spread broadly. They end up getting applied in ways the originator never intended. (Jung reportedly said "thank god i'm not a jungian")
Eric's a fine writer and one of the smartest and most interesting people I've met. Nothing "snapped in his mind" and I can tell you for certain that he never tried to "force every idea into a class hierarchy" (quite the contrary! - he's very much a programming pluralist and spent a few years working in Clojure for that very reason). Nor would he ever do something as crude as trying to force a model (any model) onto software development as a whole. He's far too inquisitive and flexible a thinker.
By the way, Eric's way of programming and of thinking about programming was formed in the Smalltalk world, well before Java existed. Like a lot of the Smalltalk diaspora who ended up working in Java (and experiencing it as a kind of exile from the powerful and flexible Smalltalk environments they were used to), he thought deeply about what the differences were and how the Smalltalk design culture could be (partly) recovered and reshaped for these other technologies. A lot of creative work came out of that, not just DDD (e.g. Ward Cunningham's work, which led to Wikipedia).
I read the whole book, and I think my gripes are with Eric’s core thesis. Modeling your software around your core business concepts is a poison in most cases. If you hard code product names, stakeholder names, and specific business processes into your core software, you’ve locked your business into a bad place. The reality is businesses domains shift regularly, especially in new and evolving companies. Instead, software should focus on business agnostic functional layers. The business domain, as much as possible, should live in configuration and data. Even for the core data models you choose, they should be flexible and business agnostic to support future types of business operation. A good test of the poison is how easy it is to add a new product/service line/workflow/stakeholder/onboard a new customer. DDD creates bespoke work and pain around these business needs.
There are probably a minority of times where you want to lock in your business concepts to your core model and service layer, like in a stagnated business that isn’t changing, or something that’s a universal domain model in that industry. The rest of the time business domains should be configured at a higher level. The linked article makes a good argument about the flexibility of spreadsheets.
Eric's a fine writer and one of the smartest and most interesting people I've met. Nothing "snapped in his mind" and I can tell you for certain that he never tried to "force every idea into a class hierarchy" (quite the contrary! - he's very much a programming pluralist and spent a few years working in Clojure for that very reason). Nor would he ever do something as crude as trying to force a model (any model) onto software development as a whole. He's far too inquisitive and flexible a thinker.
By the way, Eric's way of programming and of thinking about programming was formed in the Smalltalk world, well before Java existed. Like a lot of the Smalltalk diaspora who ended up working in Java (and experiencing it as a kind of exile from the powerful and flexible Smalltalk environments they were used to), he thought deeply about what the differences were and how the Smalltalk design culture could be (partly) recovered and reshaped for these other technologies. A lot of creative work came out of that, not just DDD (e.g. Ward Cunningham's work, which led to Wikipedia).