По своему опыту могу сказать, что DDD стоит трактовать не узко, как реализацию набора классов, моделирующих и состояние, и поведение предметной области (что заставляет архитекторов и разработчиков изначально втискиваться в рамки платформы и терминологии, в которой инкапсуляция — это строго классы, а не, например, пакеты и компоненты), а как подход к проектированию, опирающийся на предметную область, описанную единым языком (ubiquitous language). Этот подход неразрывно связан с построением информационной архитектуры в рамках проектирования UX и выглядит примерно так:
1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).
Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
На выходе получаете список потребностей заказчика в свободной форме.
2. Аналитический этап:
а) Из предложений в тексте списка потребностей выбираются существительные (подлежащие, дополнения и обстоятельства) и фиксируются в качестве сущностей домена.
б) Анализируются определения, связанные с выделенными сущностями: если определение приводит к полиморфизму, то это скорее всего новый класс, иначе — одно из значений какого-то атрибута.
в) Анализируются и классифицируются подлежащие и обстоятельства: они могут описывать операции над сущностями и связи между ними.
г) Модель, полученная по итогам анализа текста, пересматривается с учетом исключительных ситуаций и возможно пропущенных сценариев: проверяются достоверность полученной иерархии классов, возможные значения атрибутов, мощности связей и т.п. Вносятся необходимые уточнения.
На выходе получаете структурированный документ — информационную архитектуру. Информационная архитектура будет определять 80% вашей доменной модели.
3. Следующий этап — проектирование карты достижения целей пользователя (Customer Journey Map).
На этом этапе ваша задача определить кратчайший путь движения пользователя от возникновения потребности до её реализации с помощью разрабатываемой системы.
Именно здесь выделяются первые интерфейсы (без их визуализации, как сущности) и у вас появляется возможность уточнить информационную архитектуру.
На выходе у вас получается целостное описание работы приложения без иллюстраций, которое можно брать за основу для руководства пользователя.
Полученный таким образом CJM используется далее прим пользовательском тестировании приложения в качестве шаблона, который заполняется результатами тестирования для последующего улучшения интерфейса.
Кроме того, CJM фактически является готовым перечислением интеграционных тестов, которые вы можете написать (и тут DDD логичным образом перетекает в TDD).
4. Итак, поскольку вы уже полностью представляете себе, как должно работать приложение с точки зрения внешнего наблюдателя, можно приступать, к проектированию системной архитектуры и дизайну внешнего вида интерфейса: здесь в рамках DDD вам нужно просто спроецировать информационную архитектуру на платформу реализации, в том числе выбрать подходящие типы данных, механизмы реализации связей между сущностями и т.п. Здесь вы в последний раз уточните домен, выявив недостающие ограничения и взаимосвязи с помощью формального анализа логики приложения (многие ранее не учтенные особенности выявляются блок-схемами алгоритмов реализации). Важно, что вы не обязаны следовать здесь определенному архитектурному паттерну и впихивать невпихуемое в один класс, потому что кто-то сказал, что DDD — это rich model. Это не так: практически в каждом языке общего назначения инкапсуляция реализуется не только через классы, но и через их связные ансамбли с ограниченной областью видимости деталей внутреннего взаимодействия (пакеты и компоненты, пространства имен и т.п.), соответственно, сущность доменной модели может быть представлена разными способами, выбор которых зависит от особенностей вашей модели, выбранной платформы и т.п. Для вас важнее будет не конкретный выбор паттерна, а обеспечение устойчивости архитектуры к изменениям за счет точного описания сущностей предметной области, приближенного к бизнесу, и за счет снижения связности, которое вы можете обеспечить, адаптируя доменную модель к нуждам конкретных компонентов с помощью различных паттернов (DTO, фасады и т.п.).
