Переход от указанного агрегированного корня к другому агрегатному корню

В моей системе используется язык «Контакта», который является своего рода «пользователем-призраком», о котором у нас есть некоторая информация - его правила проверки тонкие, а его состояние - в основном контактная информация. У нас также есть понятие «Пользователь», который является полностью проверенным и зарегистрированным пользователем. Думайте о «Пользователе» как о конкретном «Контакте».

Жизненный цикл, который мы пытаемся уловить, заключается в том, что «Контакт» будет заменен «Пользователем», как только кто-то зарегистрируется с информацией этого «Контакта».

У нас есть и другие совокупные корни в системе, которые ссылаются на «ContactId», указывающий на UUID «Contact». Когда этот «Контакт» регистрируется, мы хотели бы использовать новую концепцию «Пользователя» для представления их в домене, и «Пользователь» теперь имеет свой собственный UUID «UserID».

  1. Как мы можем сохранить отношения, которые все еще ссылаются на «Контакт» через ContactID, чтобы теперь ссылаться на «Пользователя» через UserID?
  2. Есть ли фундаментальная проблема с попыткой перевести мой агрегат в другой?
  3. Если да, то как мне смоделировать этот конкретный жизненный цикл «Контакт» -> «Зарегистрированный пользователь»?
  4. Если ответ состоит в том, чтобы объединить две идеи в единый совокупный корень, как я могу поддерживать действительность объектов моего домена в любое время, несмотря на то, что «Пользователь» недействителен до тех пор, пока этот «Контакт» не зарегистрируется?

В качестве примечания, мы используем CQRS / ES для общей архитектуры.

Спасибо!


cqrs domain-driven-design domain-events
person Chris Tickner    schedule 26.03.2016    source источник
comment
Я бы продолжил использовать Контакт, возможно, нашел бы для него другое имя. Когда пользователь будет зарегистрирован, он получит соответствующую ссылку на поддомен аутентификации. Для других агрегатов / BC это может быть только частично интересно, если это ведущий или фактический пользователь, но если они хотят знать, вы всегда можете включить эту информацию в объект значения, в котором вы храните ссылку на контакт, вместе с именем, например   -  person Alexey Zimarev    schedule 26.03.2016
comment
Я использую термин соискатель для пользователей, которые еще не полностью зарегистрированы в одном из моих проектов. Вы также можете использовать термин Lead для продажи.   -  person Adrian Thompson Phillips    schedule 29.03.2016
comment
@ChrisTickner Почему вам нужно превратить отношения Contact в отношения User? Почему это должно волновать направляющую организацию? У вас есть пример использования для этого?   -  person guillaume31    schedule 29.03.2016

Ответы (1)


arrow_upward
2
arrow_downward

То, что вы описываете, на самом деле не так уж и странно, поскольку это происходит постоянно.

У вас может быть ShoppingCart, который становится Quote, который становится Order, который становится Invoice.

Попытка объединить концепции обычно приводит к боли и страданиям.

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

Это может быть ключ к разгадке вашего «призрачного пользователя». Вероятно, это объект / AR, который вам нужен после того, как он не был должным образом определен. Будут разные способы обработки этой концепции в зависимости от того, как она используется. Это может быть просто объект-значение, представляющий одну из двух исходных сущностей.

person Eben Roux    schedule 27.03.2016
comment
Спасибо. Есть ли смысл использовать одну AR, которая инкапсулирует и то, и другое? Например, Identity AR, у которого есть объект значения для данных контакта, а также объект User, если пользователь зарегистрирован? Или это слишком много для одной идеи? Помните, что меня больше всего беспокоит то, что другие AR хранят ссылки UUID на этот AR. - person Chris Tickner; 28.03.2016
comment
Это зависит от вашего домена. То, что вы предлагаете, не кажется слишком надуманным. Например, OrderLine может иметь OrderProduct ВО, где он имеет идентификатор Product, который был заказан. Но что произойдет, если мы обычно не храним какой-то конкретный товар? Например, когда я продаю подержанный велосипед в своем веломагазине, не будет ProductId; скорее просто Description и Price. Возможно, что-нибудь в этом роде поможет. Здесь могут помочь ваши эксперты в предметной области. - person Eben Roux; 28.03.2016