В микросервисе является ли транзакционная граница ограниченным контекстом или совокупностью?

Question

Может быть, первый вопрос должен быть таким: что поможет мне решить, должен ли мой Микросервис содержать весь ограниченный контекст, возможно, с несколькими агрегатами, или он должен содержать только один агрегат?

Если микросервис содержит несколько агрегатов, у меня возникает другой вопрос: будет ли микросервис иметь несколько транзакционных границ (по одной на агрегат) или микросервис будет иметь только одну границу транзакции (ограниченный контекст)?

Может быть, ответ на эти вопросы: это зависит. Но я хотел бы иметь какое-то обоснование для принятия правильных решений.

Я пытался реализовать экспериментальный Microservice, который реализует ограниченный контекст, состоящий из 3 агрегатов и одной транзакционной границы на агрегат, и я столкнулся с некоторыми болевыми точками:

• Возможная согласованность внутри самого Микросервиса
• Атомарное обновление агрегатов и публикация событий домена в микросервисе гибким способом
• Решение о том, должны ли все события домена быть опубликованы извне (для других микросервисов) или только некоторые из них
• Решение о том, следует ли публиковать события домена в форме событий интеграции, чтобы сохранить чистоту модели домена

Затем я предусмотрел возможность разбить микросервис на несколько микросервисов, по одному на агрегат:

• Становится более естественным публиковать все события домена (нет явной необходимости проводить различие между событиями домена и событиями интеграции)
• Внутренняя сложность микросервиса снижена

Мне не удалось найти какую-либо документацию по этому вопросу, которая могла бы помочь мне в принятии решения.

Edit:

Имеет ли смысл считать, что ограниченный контекст может представлять собой набор микросервисов, работающих вместе как партнеры, и где каждый микросервис инкапсулирует один и только один агрегат со своей собственной стратегией масштабирования?

Тогда у каждого микросервиса будет одна-единственная причина для изменения: совокупность.

Answer 1

Вы можете обычно (это зависит, как всегда) отобразить один ограниченный контекст на один микросервис.

Микросервис может использовать несколько агрегатов.

Граница транзакции - это операция, которую выполняет агрегат. Эта операция не может быть отклонена / отменена / откат ничем вне агрегата. Если агрегат говорит «ДА», то это потому, что ВСЕ бизнес-правила и инвариант проверены. Необходимость отклонить / отменить / откатить агрегатную операцию извне агрегата - запах неправильного дизайна.

СОВЕТ: Помимо чисто неправильных конструкций, мелкозернистые операции были решением многих потенциальных "отменных" встреч. Пользователь не «Оплачивает» при нажатии кнопки «Оплатить». Поскольку вам необходимо отменить зарегистрированную операцию «Оплатить» (агрегат говорит, что, насколько ему известно, пользователь может заплатить), если банк отклонит операцию. Пользователь запускает бизнес-операцию «Оплатить», которая состоит из нескольких шагов:

«Заказать платеж»: зарегистрируйте заказ и создайте событие UserOrderedPayment, если агрегат скажет «ОК». После этого все остальное - внутренние события / операции в вашей системе.

Событие UserOrderedPayment запускает начисление денег. В случае неудачи возникает событие UserOrderPaymentRejected, и Платежное поручение помечается как отклоненное. Если деньги начисляются без проблем, тогда регистрируется новый Платеж и возникает событие UserPaid.

О

Окончательная согласованность внутри самого Микросервиса

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

Атомарное обновление агрегатов и публикация событий домена в микросервисе устойчивым образом

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

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

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

Принятие решения о публикации событий домена в форме события интеграции с целью сохранения чистоты модели предметной области

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

Answer 2

Предполагая, что мы следуем подходу одного микросервиса для каждого BC, транзакционной границей является микросервис. Каждый метод обслуживания приложений BC будет транзакцией. Агрегат внутри BC определяет группу объектов домена, которые должны изменяться вместе, чтобы поддерживать инварианты. Операция с агрегатом должна быть включена в транзакцию. Таким образом, каждый метод службы приложения должен вызывать только одну агрегатную операцию.

Answer 3

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

В ваших терминах это означало бы содержать одну транзакционную границу и, возможно, несколько «агрегатов».

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