В DDD, когда вам нужно использовать модели (например, Пользователи) из одного ограниченного контекста (BC) в другой ограниченный контекст, вы должны использовать Антикоррупционный слой .Это означает, что вы можете не просто использовать ту же модель, но и упрощенную, то есть с меньшим количеством атрибутов, и она должна быть неизменной (только для чтения).
Таким образом, если пользователь является сущностью в IAC BC, со многимисвойства и поведение (чтение и запись), в Remote BC это значение объекта , то есть только его ID и Name только для чтения.ACL отвечает за перевод из удаленного объекта в локальный объект Value, который может быть безопасно использован в локальном BC.
В зависимости от вашей архитектуры ACL может быть реализован с использованием задания CRON, периодически обновлять локальные объекты Value из удаленных сущностей или может реагировать на удаленные события в случае управляемых событиями архитектур (CQRS, Eventисточники).Вы даже можете привязать oplog удаленной базы данных к почти мгновенным обновлениям.
Таким образом, каждый BC должен иметь свои собственные данные, и службы, которые в нем живут, должны иметь возможность функционировать независимо.Если сервисы в одном BC будут недоступны, сервисы в другом BC должны продолжать работать.Думайте о BC как о модулях.
Некоторые рассматривают пользовательский интерфейс как другой BC.Таким образом, в этом случае optimized SQL views может жить в этом отдельном BC и действовать как модель со встроенным ACL.Однако он не может функционировать отдельно.Он также связывает другие BC вместе, заставляя вас использовать один и тот же тип базы данных или даже экземпляр во всех BC.