Источник событий: как преобразовать один агрегат в другой

У вас есть два агрегата, но нет «конверсии». Вы вступаете на опасный путь, который может привести к превращению тележек для покупок в заказы (например).

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

1. Предполагаемый клиент создан
2. Предложение принято
3. Платежный клиент, созданный из потенциального клиента
4. Потенциальный клиент удален (или помечен как "преобразованный", или деактивированный)

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

Вам нужны обработчики событий домена, которые выполняли бы (3) и (4), поскольку вы говорите, что это тот же ограниченный контекст.

Генерация уникальной совокупной идентичности не является функцией самого агрегата, она выполняется извне, и агрегаты получают свою идентичность при создании как фабричный метод или / или параметр конструктора. Следовательно, когда вы создаете платящего клиента из потенциального клиента, ничто не мешает вам использовать ту же личность.

Однако у вас появляются предположения, что вы всегда ожидаете, что у вас будет потенциальный клиент, который сможет получить вашу историю или что-то еще, используя ту же личность. Поскольку это предположение является неявным, о нем легко забыть и, как правило, особенно не рекомендуется в DDD (помните, что неявные вещи делаются явными). Вы можете легко сохранить ссылку на идентификатор потенциального клиента в своем новом платежеспособном клиенте, и тогда все будет в порядке.

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

Когда вы конвертируете свой агрегат, вы действительно создаете новый агрегат, поэтому я бы решил эту проблему с помощью обработчика событий домена. Обработчик событий домена будет реагировать на события и выдавать команды, поэтому пусть ваш ProspectiveCustomer отправит что-то вроде OfferAcceptedEvent, на которое обработчик событий может воздействовать.

Это может быть поток процесса:

1. Пользователь принимает предложение и ProspectiveCustomer отправляет OfferAcceptedEvent.
2. Обработчик событий реагирует на OfferAcceptedEvent и отправляет CreatePayingCustomerCommand. (OfferAcceptedEvent должен содержать все данные из ProspectiveCustomer, необходимые для создания команды)
3. PayingCustomer создан

Вероятно, неплохо было бы включить ProspectiveCustomerId в PayingCustomerCreatedEvent, чтобы вы могли отслеживать PayingCustomer обратно до ProspectiveCustomer.