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

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.