DDD с микросервисами и несколькими входами через REST и очередь сообщений - PullRequest
2 голосов
/ 02 августа 2020

У меня есть совокупность root с бизнес-логами c в проекте c#. Также в решении есть проект REST web.api, который передает команды / запросы агрегату root для выполнения работы и обработки запросов. Это мой микросервис. Теперь я хочу, чтобы некоторые из моих событий / команд / запросов поступали из очереди сообщений. Я рассматриваю это:

  • Поместите консольное приложение в решение для прослушивания сообщений из очереди сообщений. Затем укажите в консольном приложении ссылку на агрегированный проект root

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

Лично я считаю, что делать то, что я предлагаю, нормально, хороший конвейер CI / CD должен смягчить это. Но есть ли еще какие-то минусы, которые я мог пропустить?

1 Ответ

0 голосов
/ 03 августа 2020

Для некоторой предыстории я бы посоветовал посмотреть DDD & микросервисы: наконец, некоторые границы! Эри c Эванс.

Ограниченный контекст - это микросервис. Другое дело, как вы это делаете. Кажется, то, что вы описываете, я делаю довольно часто. У меня есть проект с открытым исходным кодом Identity & Access , над которым я работаю (поэтому в зависимости от того, когда вы его читаете, он может быть в другом состоянии), который демонстрирует эту структуру.

Internal to в организации можно получить доступ к B C либо через служебную шину, либо через web-api. Внешние стороны будут использовать только веб-api, поскольку обмен сообщениями не должен быть открыт. Web-api либо возвращает данные из уровня запроса , , либо отправляет команды через служебную шину (обмен сообщениями) в функциональную конечную точку B C. В зависимости от сложности системы я могу представить проблему оркестрации, которая взаимодействует с несколькими BC. Вероятно, это B C сам по себе, во многом похожий на отчетный B C.

...