Я продолжу.

В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space).

Свидетельство этого можно обнаружить, например, в спецификации ArchiMate: "Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology".

DDD отличается тем, что Application Model разделяет (shared) Business Model, что и образует ubiquitous language.

Обратите внимание, Event Stroming начинается с исследования предметной области (Big Picture), а заканчивается проектированием системы (Software Design или Modeling software systems) на той же самой диаграмме, которая после реализации практически 1:1 будет отражать структуру кода.

Можно даже не создавать никакой отдельной диаграммы (как и модели) для Application Layer:

💬 Work on the existing model. Modeling processes, injecting new concepts on top of the existing artifact works well in small groups scenario and/or when you have the possibility of a full-day (or more than one day) workshop.
-- Introducing EventStorming by Alberto Brandolini

💬 Big Picture workshop tried hard not to focus but to embrace the whole complexity and maximize learning. Now the starting point is different: * we can assume we have a shared better understanding of the underlying domain here the focus is on implementing software features that are solving a specific problem.
...
Here we are trying to find one or more solutions to a problem worth solving. This means that the workshop isn’t over until we have something that looks like a robust candidate solution.
...
the big picture was a model of our current level of understanding, by digging deeper into key interaction we are already making it obsolete.
-- Introducing EventStorming by Alberto Brandolini

💬 Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a fluent ubiquitous language.
-- DDD Reference by Eric Evans

Вот что скрывается за фразой ubiquitous language. Это, наверное, наиболее существенный отличительный признак DDD.

Продолжение...