Дублирование данных между двумя агрегатами

Question

Два ограниченных контекста, реализованных в виде микросервисов:

• Управление пользователями
• Бухгалтерский учет

Управление пользователями содержит агрегат User с его Name, Email и т. Д.

Некоторые User с, с другой стороны, становятся Customer с в пределах Бухгалтерский учет ограниченный контекст.Customer имеет свои собственные рабочие процессы, поэтому он сам по себе является агрегатом.Его создание инициируется событием UserRegistered (механизм публикации / подписки).

Чтобы отправить счет, Accounting необходим адрес электронной почты Customer.Мне интересно, должен ли адрес электронной почты (чей мастер данных User) стать частью совокупности Customer, что повлекло бы за собой синхронизацию каждого изменения адреса электронной почты User.

Другое решение, которое я склонен считать более чистым, - проецировать email address (и его изменения) на readmodel в Accounting .Таким образом, совокупность Customer является хозяином данных своего собственного состояния (например, процесса обработки платежей), но не данными, уже предоставленными User.

Что вы думаете?Является ли дублирование данных между двумя агрегатами вообще плохим делом?

Answer 1

Что ты думаешь?Является ли дублирование данных между двумя агрегатами, вообще говоря, плохим занятием?

Нет.Нет ничего плохого в том, чтобы иметь одну «основную» копию, принадлежащую органу управления данными, и несколько подчиненных копий.Если полномочия полностью находятся за пределами вашей модели, тогда все ваши копии могут быть подчинены действительным полномочиям.

Дубликаты копий данных поддерживают автономность - даже если мастер в настоящее время недоступен, другие компонентыв системе можно продолжать прогрессировать, используя свои локальные копии данных.

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

(Помните, что недействительность кэша является одной из двух трудных проблем).

Упрощенный пример этого может быть оплаченный статус счета.Ваша система выполнения может нуждаться в том, чтобы узнать, был ли оплачен счет, прежде чем он сможет отменить отправку.Ваша биллинговая система владеет решением, что счет был оплачен.Между ними есть небольшой кусочек информации.

Но копия этих данных в системах исполнения является подчиненной - система исполнения не имеет права отклонять оплаченный счет.(Разумеется, он может иметь полномочия выдавать отчеты об исключениях «мы не можем выполнить требования договора купли-продажи» или что-либо подобное).