/// продолжение В чем тут потенциальные проблемы? - Двойные усилия, – параллельно из двух сервисов вычищается ненужный код - Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого. - Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например). Вывод Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели. Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂 PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation