Используйте DB Relationships в весенних загрузочных микро сервисах

Question

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

Пример:

Существует одна служба userDeatil, а другая - услуга productDetail. Теперь существует третья служба под названием orderDetail, и заказу будут присвоены идентификаторы userID и ProductID.Так, как мы можем управлять отношениями между «пользователем и заказом» и «заказом и продуктом».

Я искал по сети, но не смог получить честную идею. Есть еще один поток, имеющий тот же запрос, ноне имея четкого ответа. Link

Answer 1

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

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

Думаю, вам следует переосмыслить ограниченный контекст ваших микросервисов.Следует помнить:

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

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

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

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