Как/куда загрузить объект значения, который является сущностью в разных BC в системе на основе DDD и CQRS/ES

Я прошел этот замечательный учебник: http://www.cqrs.nu/tutorial/cs/01-design и пытаюсь сделать свое приложение таким же образом.

По моим предыдущим вопросам я знаю, что то, что является сущностью в одной БК, может быть представлено как объект-значение, содержащий идентификатор сущности в другой БК и, опционально, любой другой параметр. (Я поместил эти идентификаторы в Core BC.)

Теперь, допустим, у меня есть два БК: PlansEditor и Subscribing.

В PlansEditor, если есть Editor (человек с ролью), когда он создает Plan с некоторыми параметрами, такими как frequency и vip, то создается Plan.

В Subscribing при наличии Customer и нескольких доступных Plan, когда клиент подписывается на Plan, создается Subscription.

В планах тут может быть просто ВО с параметрами частоты и VIP, т.к. Подписке нужны именно они (для защиты инвариантов). Но клиент нажимает, чтобы подписаться на план, и отправляется запрос с идентификатором плана.

Итак, я начинаю свой жизненный цикл BC с идентификатором клиента и идентификатором плана, на который он подписался. Мне нужно загрузить/создать этот Plan «объект значения» (который на самом деле является сущностью в PlansEditor до н.э.) где-то по заданному идентификатору.

Где и как мне получить этот План VO в Subscribing г. до н.э.?

Я думал на прикладном уровне через Event Repository - чтобы можно было отправить SubscribeCustomerToPlanCommand(Customer, Plan) содержащее это значение объект. Но тогда Subscribing BC нужно будет знать, что Plan как объект в PlansEditor существует, чтобы загрузить его и преобразовать в Plan как VO, что неприемлемо - для правильного функционирования одному BC потребуется другой.

Или я должен просто получить информацию, необходимую для создания Plan VO из некоторой модели чтения, и сделать это на прикладном уровне, удобно ли это? Или как и где? :)


person Tom    schedule 15.03.2017    source источник


Ответы (1)


Насколько я могу судить, Plan не будет озвучивать ни в том, ни в другом контексте. Дело не в том, что один BC имеет полномочия на жизненный цикл объекта, поэтому объект становится VO в других контекстах (это могло бы быть).

Если нижестоящему контексту необходимо быть в курсе жизненного цикла объекта в удаленном контексте, то этот объект, вероятно, следует моделировать как объект и в нижестоящем контексте.

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

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

«BC затем необходимо знать, что Plan как сущность в PlansEditor существует, чтобы загрузить его и преобразовать в Plan как VO, что неприемлемо — одному BC потребуется другой для правильного функционирования»

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

person plalx    schedule 16.03.2017
comment
На самом деле, когда редактор удаляет план, все подписчики этого плана в Subscribing BC должны оставаться подписанными на (любой) план с теми же параметрами, что и при подписке. Не разрешать подписку только новым подписчикам, потому что ее не существует (в PlansEditor до н.э.). Но мне кажется слишком сложным поддерживать Plan объект в подписке BC, просто потому, что я вполне доволен фактической копией состояния Plan в PlansEditor BC в Plan VO в определенное время при подписке. - person Tom; 16.03.2017
comment
@Tom Ну, в этом случае Plan может быть VO, который вы все еще приобретаете через службу, которая является частью антикоррупционного уровня контекста вашего подписчика. Имейте в виду, что у вас не может быть сильной согласованности между обоими контекстами (например, клиент может подписаться на план, который только что был деактивирован). - person plalx; 16.03.2017
comment
Чтобы добавить мой ZAR0.02 :) --- согласен, объект не обязательно является VO в нисходящем направлении, но у вас, вероятно, есть другое представление этой концепции... так что, возможно, SubscribedPlan или что-то в этом роде. Это означает, что вышестоящий BC по-прежнему является системой записи, и вы должны обрабатывать все атрибуты, принадлежащие этому BC, в своего рода VO, поскольку вы определенно не должны не изменять их, но использовать шаблоны интеграции для последующего обновления. Вы можете свободно изменять значения, принадлежащие вашему нисходящему BC. - person Eben Roux; 16.03.2017
comment
@EbenRoux Концепция может быть названа Plan в обоих контекстах, оставаясь при этом другим представлением. Вы подписываетесь на Plan, а не на SubscribedPlan. - person plalx; 16.03.2017
comment
Да, можно было бы сделать это. Я думаю, это будет зависеть от того, что используют эксперты в предметной области ... так что в значительной степени сосредоточено вокруг UL. Однако, если это другое понятие, легче рассуждать о том, имеет ли оно отличное имя, представляющее это понятие. Но согласитесь, вы можете использовать то же имя. В BC Identity & Access есть User, но мы вполне можем назвать его как-то иначе в другом BC. Просто думаю в этом направлении. - person Eben Roux; 16.03.2017
comment
@plalx Отлично, спасибо, антикоррупционный слой решает мою проблему! Это также привело меня к контекстным картам и целой главе 14 в моей только что доставленной большой синей книге Эвана. Обнаружен еще один недостающий элемент в этом подходе :) - person Tom; 16.03.2017