Здесь фундаментальное непонимание того, что такое DDD.

Главную цель DDD Evans позаимствовал из MODEL-DRIVEN DESIGN:

💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

В DDD нет "программной модели" в вакууме. Есть единая, вездесущая модель, которая одинакова и для Problem Space (предметка) и для Solution Space (модель, воплощенная системой).

Единство и вездесущность модели обеспечивается посредством Ubiquitous Language, на котором общаются и эксперты предметной области, и разработчики.

В Event Storming это достигается тем, что этап моделирования системы может делаться прямо на тех же стикерах, которые получились в результате исследования предметной области.

Это главный постулат DDD.

Стремясь его достигнуть, Evans столкнулся с проблемой, что различные эксперты предметки, имеющие различные интересы и обязанности, один и тот же оригинал моделирования называют разными терминами. Был "покупатель", стал "плательщик", и станет "получателем".

Тогда он понял, что выбор термина зависит от того, какую проблему решает модель. А граница согласованности языка определяет границу модели. Так он открыл Bounded Context.

Потом он понял, что модель - это то, что позволяет гранулировать знание о системе. Это знание нельзя разорвать между командами разработки, т.к. резко подскочит коммуникативная нагрузка между командами. И нельзя смешивать несколько знаний воедино, т.к. нарушится главный посулат модели - упрощение, и возрастет паразитная когнитивная нагрузка. Так он открыл границы автономности команды разработки.