Совместное использование агрегатов между микросервисами

Ранее я задавал вопрос о том, как уведомления и пользователи, которые видят эти уведомления, могут быть смоделированы в DDD.

Ссылка здесь: Все ли должно быть в совокупности? Связь «многие ко многим»

Кратко об этом:

Мы можем создавать уведомления в системе, которые мы хотим показывать пользователям. (Уведомление будет нацелено на определенных пользователей, для которых вы определяете фильтр. Например, показывать только администраторов, показывать только обычных пользователей, показывать только пользователей для клиента x). Когда пользователь видит уведомление, мы хотим пометить его, чтобы он его не видел. снова.

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

Итак, у нас есть список уведомлений в файле user.

Я думаю, что это ограниченный контекст (контекст, ограниченный уведомлением). Конечно, если бы я моделировал его как микрослужбу, я бы обрабатывал эти уведомления в отдельной микрослужбе.

Если бы мы использовали микрослужбы, событие, созданное пользователем, пришло бы из другой службы (службы пользователей).

Вопрос: Создание уведомления будет происходить в микросервисе уведомлений. У меня также возникнет соблазн пометить пользователя, что он также видел уведомление в этой службе.

Таким образом, на этом этапе микрослужба уведомлений не будет содержать полную совокупность пользователей, а будет иметь только частичную, содержащую; идентификатор, сбор уведомлений и любые критерии, которые могут потребоваться для фильтрации

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

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

Однако хотим ли мы хранить все пользовательские данные в одном месте? даже если он добавляет в него другие функции? Будет ли уведомление отображаться в пользовательском микросервисе (это неправильно)

Спасибо


microservices aggregate event-driven domain-driven-design bounded-contexts
person Matster2    schedule 22.05.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Можно ли иметь агрегат (будь то частичный, поскольку это только то, что нам нужно) в микросервисе (микросервисе уведомлений), которому он не принадлежит?

То, что вы называете «частичным агрегатом», я бы назвал проекцией агрегата, принадлежащего отдельному BC. Таким образом, эта проекция может принадлежать BC, представленному в импортирующей микрослужбе. В этом смысле да, нормально.

Таким образом, по сути, у нас есть совокупность пользователя в микросервисе пользователей и уведомления.

Нет, не знаешь. У вас есть Пользователь в его БК, и у вас есть проекция Пользователя в БК Уведомлений. BC может владеть проекциями агрегатов из других BC, но не самими иностранными агрегатами. Вы хотите проецировать только то, что вам нужно от других BC, а не все. Если это было все, то вы в значительной степени нарушили какой-то фундаментальный DDD. А с физической точки зрения у вас может возникнуть соблазн поделиться базами данных и т. д., что противоречит некоторым признакам хорошей микросервисной архитектуры.

Вопрос: Создание уведомления будет происходить в микросервисе уведомлений. У меня также возникнет соблазн пометить пользователя, что он также видел уведомление в этой службе.

Я думаю, это было бы нормально. Это звучит так из контекста вашего вопроса (я, конечно, не знаю всего, что вы делаете). Возможно, в вашем BC Notifications у вас есть NotifiedUser со списком уведомлений или, возможно, наоборот SeenNotifications со списком пользователей.

person Kit    schedule 22.05.2020
comment
Спасибо за ваш комментарий. Я думаю, что согласен, но, возможно, не использовал терминологию. Поэтому я согласен с тем, что не имею полной совокупности пользователей в уведомлениях BC. Вам нужны только те данные от пользователя BC, которые необходимы. Однако, хотя это и не совокупность пользователей (как ее видит пользовательский контекст), не будет ли она по-прежнему моделироваться как совокупность, но только с этой ограниченной информацией, любой конкретной информацией, добавляемой контекстом уведомлений. Поскольку агрегаты используются для моделирования инвариантов. Возможно, проще понять, когда вызывается NotifiedUser, но это будет совокупность - person Matster2; 22.05.2020
comment
Я думаю, мы могли бы взять ваши комментарии и мой ответ и объединить их. У вас есть NotifiedUser, который действительно является агрегатом, но в теле NotifiedUser у вас может быть спроецированная информация о пользователе, которая вам нужна в качестве объекта дочернего значения, например. NotifiedUser.UserInfo. Главное - не делиться агрегатами дословно ... если дословно, я бы сказал, что ваш дизайн ошибочен. - person Kit; 22.05.2020
comment
Но что, если это то же самое? Добавление другого имени или даже оболочки для этого пользователя (поскольку вы предполагаете, что пользователь является объектом значения) кажется странным для этого. Я понимаю, что некоторые ограниченные контексты имеют разные имена для вещей, например. бухгалтерия рассматривает клиента как учетную запись, но пользователь здесь кажется подходящим. Имя является общим, идентификатор и любые данные, которые служба уведомлений считает подходящими (например, клиент, под которым находится пользователь, и роль). - person Matster2; 22.05.2020
comment
Месяцы спустя... Я думаю, что для иностранной организации нормально быть на 100% идентичным ее прогнозу в импортирующей БК. Я не знаю правила, запрещающего это. Предполагая, что это нормально, я все равно не стал бы делиться типом, потому что, как только вы измените его в исходном BC, вы автоматически поделитесь этими изменениями в импортированном BC... скрытый недостаток моделирования, если хотите. Но ваша точка зрения, в просторечии, что утка есть утка, где бы она ни была, может быть справедливой! - person Kit; 07.07.2020