Веб-приложение API Microservice - Domain Driven Design: нормальное ли количество дублированных данных?

Question

Итак, я пытаюсь овладеть микросервисами. Каждый сервис должен стоять сам за себя, насколько я понял. В моем примере у меня есть Unit.API и Combat.API. Unit.API db содержит около 1 000 000 различных единиц.

Теперь, если я хочу вычислить / создать battleLog в Combat.API, мне нужно каким-то образом узнать, какой пользователь использовал какие юниты.

подход 0: неправильный подход, поскольку Я понял :
В методе post контроллера я получаю все unitIds в качестве параметров, а затем вызываю Unit.API, чтобы получить единицы.

подход 1 : правильный подход?:
У меня есть дубликат каждой единицы из Unit.API в моем Combat.API. В методе post контроллера я получаю все идентификаторы в качестве параметров и получаю "копии" элемента battleUnit из Combat.API db. Всякий раз, когда юнит меняется, мне нужно отправить событие с Unit.API на Combat.API, чтобы сделать там такое же изменение.

подход 2: тоже неправильно?:
В посте Метод контроллера Я получаю все единицы напрямую через параметры.

Я думаю, что подход 1 на самом деле правильный, но для меня он кажется неправильным. В каждую минуту могут быть тысячи изменений в единицах, и мне нужно было бы отправлять тысячи событий только для того, чтобы обновлять другую базу данных. Что здесь правильно?

Answer 1

Подход 0: Это, кажется, самое легкое решение, но здесь вы столкнетесь с неким "соединением инфраструктуры". Что это значит? Это означает, что когда Unit.Api выйдет из строя или выйдет из строя, Combat.Api также не будет работать, поскольку это зависит от обслуживания юнитов.

Подход 1: Это своего рода решение "по книге". Вы дублируете данные, но благодаря этому у вас есть независимые сервисы.

Подход 2: Для меня это выглядит как обходной путь:)

Прежде всего, вы должны стремиться к созданию независимых сервисов, если вы собираетесь использовать микросервисную архитектуру. Но в некоторых случаях наличие тесного общения между ними также может быть узким местом и его трудно поддерживать.

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

Более того, я думаю, вам следует еще раз взглянуть на ваша архитектура ... Я не знаю, каково будет использование и назначение Unit.API, но если он используется только Combat.API, может быть, это один микросервис / boundedcontext?