Как обновить общую информацию между двумя представлениями одного и того же объекта в разных контекстах?
Этот вопрос связан, но более конкретен, чем этот вопрос.
Я собираюсь использовать простой пример здесь. Скажем, у нас есть User сущность в одном контексте и Customer сущность в другом контексте. Это 2 разных представления одного и того же объекта.
Скажем User а также Customer у обоих есть адрес электронной почты, но адрес электронной почты всегда изменяется через ограниченный контекст, User принадлежит. Таким образом, пользовательский контекст является источником правды для адреса электронной почты. Так что в идеале я хотел бы, чтобы адрес электронной почты в Customer контекст должен быть неизменным с точки зрения контекста клиента.
Поэтому, когда адрес электронной почты изменяется в контексте пользователя, EmailAddressChanged событие испускается. Это отлично; Я подписываюсь на событие в Customer контекст. Однако теперь мне нужно обработать это событие, изменив Customer адрес электронной почты. Поэтому мне нужен какой-то командный метод, чтобы сделать это изменение.
Как я могу убедиться, что командный метод не используется, кроме как при обработке события из User контекст?
Если я разрешу мутации в обоих контекстах, то они оба станут источниками правды, и мне нужно удвоить количество событий и обработчиков, чтобы гарантировать, что информация остается согласованной в обоих контекстах
1 ответ
Может быть, между этими ограниченными контекстами существуют скрытые отношения между клиентом и поставщиком? Если User до н.э. является источником истины для Customer до н.э., тогда User bc может предоставить доступ к API для нижестоящих контекстов (Customerможет что то большее?). В своем вопросе вы сказали, что только адрес электронной почты должен быть "неизменным" и зависеть от User контекст - однако, я думаю, что это может быть намек на то, что весь Customer контекст является потребителем / клиентом User context и должен использовать его публичный API (который не должен предоставлять модель внутреннего пользовательского домена напрямую - некоторые классы фасада требуются, чтобы скрыть детали).
Если это не так, и между контекстами нет такой связи - вы можете использовать специализированный компонент в Customer bc вносить изменения в базу данных без непосредственного вызова методов домена. Затем репозиторий можно использовать для запроса клиентов и воссоздания их с обновленным адресом электронной почты. Моя точка зрения - если вы хотите, чтобы клиент bc подал заявку EmailAddressChanged события, очевидно, вам нужно что-то изменить базу данных, но вам не нужно делать это с помощью методов домена. Компонент, применяющий EmailAddressChanged события будут частью уровня инфраструктуры Customer контекст. Если вы используете это решение, то нет риска изменить клиентов с помощью сценариев экономического обоснования.
Кстати, не твой Customer на самом деле специализированная модель чтения User контекст?