DDD / Event Sourcing, получение данных из другого микросервиса?

Question

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

Служба заказа сама принимает команды, которые генерируют события, а служба фактического заказа слушает свое собственное событие для создания модели чтения (идея заключается в том, чтобы использовать CQRS,поэтому команды для записи и запросы на чтение)

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

Порядокна самом деле есть иждивенцы, что означает, что для заказа нужны клиент и продуктТаким образом, у меня будет 2 дополнительных микросервиса для клиента и продуктов.

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

Итак, вернемся к проблеме. Для создания заказа необходим заказчик (и продукты), в настоящее время у меня есть customerId на клиенте, поэтому, отправляя команду службе заказа, я могу передать customerId.

Я хотел бысохранить имя и адрес клиента с заказом. Как я могу получить имя и адрес customerId из Службы поддержки клиентов в Службе заказов?

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

Может ли служба заказа создать событие для получения записи о клиенте? Это создаст много сложностей (больше событий) в системе

Микросервисы НЕ связаны, поэтому служба заказа не может просто вызвать модель чтения клиента.

Кто-нибудь может помочь мне в этом?

Answer 1

Если вы используете DDD, прежде всего, пожалуйста, ознакомьтесь с ограниченным контекстом. Забудьте микросервисы, они просто стратегия реализации.

Теперь вернемся к вашей проблеме. Опубликуйте эти события из совокупности клиентов (в вашем случае - микросервис клиента): CustomerRegistered, CustomerInfoUpdated, CustomerAccountRemoved, CustomerAddressChanged и т. Д. Затем подпишитесь на службу заказа (снова в вашем сервисе приложений в микросервисе заказа), чтобы прослушать всевыше событий. Хорошо, не все, только какой заказ нужен.

Теперь у вас может возникнуть вопрос, а что, если большинство или некоторые из моих клиентов не делают заказы? Мой сервис заказов будет полон ненужных данных. Это хороший подход?

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

Answer 2

Когда данные одного сервиса нуждаются в данных другого сервиса, как я могу получить эти данные?

Вы копируете их.

Так что где-то в вашем дизайнедолжно быть сообщение, которое переносит данные от того места, где оно должно быть.

Это может означать, что служба заказа подписывается на события, публикуемые клиентом. обслуживание и хранение копии информации, которая ему нужна. Или может быть так, что служба заказа запрашивает некоторый API, который имеет прямой доступ к данным, хранящимся в службе поддержки клиентов.

Запросы на дополнительные данные, которые вам нужны, могут быть синхронными или асинхронными - возможно, работа может быть отложенапока у вас не будут все необходимые данные.

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

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

Answer 3

Мое предложение состояло бы в том, чтобы собрать необходимые данные во внешнем интерфейсе и передать их вместе. Соответствующие данные клиента, которые вы хотите денормализовать в заказе, будут объектом значения. То же самое касается данных о продукте (например, id, описание), связанных со строкой заказа.

Не исключено, что системы взаимодействуют для извлечения данных, но это связывает их на более низком уровне, который кажется необходимым.