Дублирующая бизнес-логика во внешнем интерфейсе с внутренним компонентом микропроцессорной службы DDD

Question

Вот абстрактный вопрос с последствиями для реального мира.

У меня есть два микросервиса;давайте назовем их CreditCardsService и SubscriptionsService.

. У меня также есть SPA, который должен использовать SubscriptionsService, чтобы клиенты могли подписаться.Для этого у SubscriptionsService есть конечная точка, в которой вы можете POST модель подписки для создания подписки, и в этой модели creditCardId указывает на кредитную карту, которая должна оплачивать подписку.Существуют определенные бизнес-правила, которые указывают, можете ли вы использовать указанную кредитную карту для подписки (срок действия истек более 12 месяцев, это VISA и т. Д.).Эти конкретные бизнес-правила связаны с SubscriptionsService

. Проблема в том, что команда, работающая в SPA, хочет конечную точку /CreditCards в SubscriptonsService, которая возвращает все действительные кредитные карты пользователя, которые могут бытьиспользуется в модели подписок.Они не хотят реализовывать те же правила проверки бизнеса в SPA, которые находятся в самом SubscriptionsService.

Мне кажется, это идет вразрез с принципами SOLID, которые являются центральными для проектирования микросервисов;конкретно разделение интересов.Я также спрашиваю себя, какой прецедент это собирается создать?Нам нужно добавить конечную точку /CreditCards в Службу OrdersService или любую другую службу, которая может использовать creditCardId в качестве свойства своей модели?

Итак, главный вопрос заключается в следующем: как лучше всего это спроектировать?Следует ли дублировать логику проверки бизнеса между внешним и внутренним интерфейсом?Должна ли эта новая конечная точка быть добавлена ​​к SubscriptionsService?Должны ли мы попытаться упростить бизнес-логику?

Answer 1

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

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

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

Обязательная ссылка Фаулера: Шаблон ограниченного контекста

Answer 2

Каков наилучший способ создать это?Следует ли дублировать логику проверки бизнеса между внешним и внутренним интерфейсом?Нужно ли добавить эту новую конечную точку в сервис SubscriptionService?Должны ли мы попытаться упростить бизнес-логику?

С моей точки зрения, я бы интегрировал «Subscription BC» (S-BC) с «CreditCards BC» (CC-BC).CC-BC находится в восходящем направлении, а S-BC - в нисходящем.Вы можете сделать это с помощью REST API в CC-BC или с очередью сообщений.

Но я проверяю, что операция выполняется с CC, а не с самим CC, т. Е. Validate ", является ли этот CC действительным для подписки».И эта проверка выполняется в S-BC.

Если SPA хочет получить "CC пользователя, которые он / она может использовать для подписки", это функциональность S-BC.

Клиент (SPA) должен вызвать API S-BC, чтобы использовать эту функциональность, а S-BC выполняет функцию, получая CC от CC-BC и выполняя проверку.

Answer 3

Даже если источником правды является модель домена, и в конечном итоге вы должны пройти валидацию на уровне модели домена, валидация все равно может выполняться как на уровне модели домена (на стороне сервера), так и в пользовательском интерфейсе (на стороне клиента).Проверка на стороне клиента - большое удобство для пользователей.Это экономит время, которое они могли бы потратить на ожидание возврата к серверу, который может вернуть ошибки проверки.С точки зрения бизнеса, даже несколько долей секунд, умноженных сотни раз в день, тратят много времени, денег и разочарований.Простая и немедленная проверка позволяет пользователям работать более эффективно и производить более качественный ввод и вывод.Так же, как модель представления и модель предметной области различны, проверка модели представления и проверка модели предметной области могут быть схожими, но служат другой цели.Если вас беспокоит DRY (принцип «Не повторяйте себя»), учтите, что в этом случае повторное использование кода также может означать связывание, и в корпоративных приложениях более важно не связывать серверную сторону с клиентской, чем следоватьСУХОЙ принцип.(Книга NET-Microservices-Architecture-for-Containerized-NET-Applications)

Answer 4

Это совершенно справедливый запрос, и вы должны предложить эту конечную точку .Если вы определяете правила для того, какой CC действителен для вашего сервиса, вы должны предложить любую помощь для его решения.

Логика не должна повторяться. Это имеет тенденцию создавать системыunmaintainable.

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

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