Ich denke, Stefan fasst den Punkt viel weiter als die Diskussion um bestimmte Patterns und ich stimme dem zu, vielleicht sogar noch weiter als vom ihm ursprünglich vorgesehen.
Zunächst muss man sich mal überlegen, in welchen Situation DDD überhaupt von Relevanz ist. Aus meiner Sicht ist das Konzept eng mit komplexen Individualprojekten mit Microservices oder Systemlandschaften verbunden.
Aber welchen Anteil machen die in der großen Welt der Softwareentwicklung aus?
In meiner ganz persönlichen und nicht repräsentativen Sicht arbeiten die meisten Softwareentwickler doch an Commercial-off-the-Shelf (COTS) Software, Embedded Systemen oder kleineren Web-Projekten. Man nehme nur die vielen Software Entwickler, die für die großen Industrieunternehmen (Microsoft, Google, SAP, Siemens, Bosch, Daimler, VW/Cariad...) arbeiten.
Auch die hier vertretenden Architekturmuster sind in der Realität breit gefächert. Oft reicht der gute alte 3-Schicht-Deployment-Monolith (intern modularisiert) doch sehr weit. Weit soll hier heißen in den Bereich von Millionen Lines of Code.
Oft sind auch ganz andere Architekturmuster gefragt, wie Pipes-and-Filters (incl. ihrer verteilten Varianten wie Hadoop und Spark), Event getriebene Architekturen oder Microkernel Architekturen (mit "Plugins").
Gerade in technischen Domänen ist die "Business Logik" eher trivial, es geht eher um die performante Verarbeitung (Speicherung, Sortierung, Auswertung, Transformation) von großen Datenmengen.
Und dann gibt es ja auch die technischen Frameworks, die ein Stück die Architektur und Patterns vorgeben. Oft macht es keinen Sinn, diese mit Dogmas zu bekämpfen. Oft verliert man dann die Effizienz, die diese zumindest für mittelgroße Projekte geben können.
Wie gesagt, DDD hat seine Berechtigung. Für einige Berater vielleicht auch das Ding. In der großen Welt der Software aber nur ein Konzept von vielen.