Переход на указанный корень агрегата на другой корневой узел

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

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

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

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

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

Спасибо!

источник

2016-03-26 Chris Tickner

Я бы продолжал использовать Контакт, возможно, найду другое имя для него. Он получит соответствующую ссылку на поддомен аутентификации, когда пользователь будет зарегистрирован. Для других агрегатов/БК может быть только частично интересно, если это ведущий или фактический пользователь, но если они хотят знать, вы всегда можете включить эту информацию в объект значения, в котором вы сохраняете ссылку Contact, наряду с именем, например –

Я использую термин * Заявитель * для пользователей, которые еще не зарегистрированы полностью в одном из моих проектов. Вы также можете использовать срок продажи * Lead *. –

@ChrisTickner Зачем вам нужно превратить отношения «Контакт» в отношения «Пользователь»? Зачем нужен референтный субъект? Есть ли у вас пример использования? – guillaume31

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

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

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

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

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

источник

2016-03-27 07:07:24

Спасибо. Можно ли использовать один AR, который инкапсулирует оба?Например, AR «Идентичность», которая имеет объект Value для данных «Contact», а также «Пользовательский» объект, если пользователь зарегистрирован? Или это слишком много добавляет в одну «идею»? Помните, моя главная проблема здесь заключается в том, что другие AR хранят ссылки UUID на этот AR. –

Это зависит от вашего домена. То, что вы предлагаете, звучит не слишком далеко. Например, «OrderLine» может иметь «OrderProduct' VO, где он имеет идентификатор« Продукта », который был заказан. Но что произойдет, если мы обычно не будем хранить конкретный товар? Например, когда я продаю подержанный велосипед в своем цирковом магазине, не будет 'ProductId'; а просто «Описание» и «Цена». Возможно, что-то вроде этого поможет. Ваши специалисты по региону должны быть в состоянии помочь здесь. –

Переход на указанный корень агрегата на другой корневой узел

ответ

Смежные вопросы