Как выделить услуги по составу услуг хореографии

Question

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

Несколько дней назад я читал о плюсах и минусах хореографии в оркестровке в архитектуре микросервисов, и я столкнулся с этой темой, скажем, у нас есть система, которая состоит из 3 сервисов: заказ, оплата, отгрузка. если я использую оркестратор, он знает, когда и как позвонить в каждую службу. на самом деле его обязанность состоит в том, чтобы знать, как и когда вызывать какую услугу, но в хореографии я понятия не имею, когда платежная служба не знает, существует ли служба заказа, как она собирается подписаться на свое событие (наверняка по крайней мере система заказа должна иметь оплату модели)?

я становлюсь более запутанным, когда начинаю думать, что если у нас есть метод заказа услуг, который возвращает информацию о заказе, за которой следуют данные об оплате и данные о доставке. как будет возвращать данные об оплате и доставке?

Answer 1

когда платежная служба не знает, существует ли служба заказа, как она собирается подписаться на свое событие (наверняка, по крайней мере, система заказа должна иметь модели оплаты)?

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

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

как будет возвращать данные об оплате и доставке?

В зависимости от сложности процесса агрегирования у вас может быть либо третья служба, отвечающая за бизнес-область, которая зависит от услуг оплаты и доставки, либо у вас есть выделенный компонент-агрегатор, который позволит объединять / разбивать запросы с фронта. конец (иногда реализуется как часть шлюза API). Если ваша логика агрегирования сложна, создайте выделенный сервис, в противном случае вы можете использовать универсальный агрегатор.