たとえば、ユーザーがワークフローの支払いステップに入ると、支払い、電子メールの生成、コンテンツの生成など、さまざまなサービスを呼び出す必要があります。フロントエンドはこのタイプの要求を処理するサービスを設計する必要がありますか？もしそうなら、どのようにそれらの要求が構成されているかをハードコーディングせずに複合要求を処理できるように、そのサービスを設計する必要がありますか？マイクロサービスアーキテクチャでは、複合データ要求を処理し、マイナーデータ処理を行い、他のサービスを呼び出す必要がありますか？
あなたは抽象的、ビジネスロジックにBPELの線に沿って何かを探しています。これを外部化する必要が明示的に必要な場合を除き、そうしないことを強くお勧めします。テストするのがはるかに難しく、サービスが大幅に複雑になります。言われて、あなたはおそらく、あなたが通話の詳細から絶縁されているように、ファサードを使用して他のサービスをラップすることを
。これにより、ロジックをテスト可能にすることができ、それらのサービス実装を他のアプリケーションとは独立して変更することができます。
本当にあなたが何を参照しているかによって異なります。あなたは複合UIを構築する必要があり、ユーザー・インターフェースではコンポジットUI
。 （マイクロ）サービスは、水平レイヤの代わりに垂直のサービスを担当する必要があります。たとえば、ビジネスレイヤーやデータレイヤーは、財務、販売などの業種に置き換える必要があり、これらの中ではさらに小さなコンポーネントを構築することができます。これらのコンポーネントは、ストレージからユーザーインターフェイスまでのビジネス上の問題を技術的に担当します。私は主にAngularJSのようなフレームワークを使用していますが、UIの一部がデータを要求し、さまざまなサービスがデータに追加できます。たとえば、Amazonでのおすすめの書籍のリスト。あなたは1つの製品IDにマップするURLから始めます。 ServiceAからの書籍情報、ServiceBからの価格、ServiceCからの出荷費用、ServiceDからの割引などを検索します。また、推奨書籍のリストもあります。このリストには、ServiceB（たとえば）からの複数の製品IDが含まれています。これらは、& image urlのような書籍情報のServiceAへの複数の要求に再び含まれます。
これで、請求書は同じものでも、電子メールでもかまいません。あたかもそれが合成UIであるかのように作成してください。
統合
あなたは、外部システムと通信できるようにするには、データを取得したいは、例えば、ユーザーインターフェイスはありません。それは財政や販売などに属しません。たとえば、IT/Opsという新しい境界を作成します。その責任は、例えば、第三者との統合です。それはこの問題を所有しています。
その後IProvideBookInformationとIProvideBookPriceようないくつかのインターフェースを定義することができます。 IProvideBookInformationはBookInfo ProvideBook(Guid id)のような方法を持つことができ、BookInfoはこのIT/Opsサービスが所有するDTOです。
その後SalesとFinanceは、このインタフェースを実装するための責任があります。したがって、彼らはこのインタフェースに依存しています。次に、好きな方法でこれを展開します。たとえば、.NETの世界ではNuGetを使用できます。次に、このIT/Opsサービスの展開時に、これらのインターフェイスを実装する他のサービスからコンポーネントを展開します。これは、ユーザーインターフェイス用のデータを提供するいくつかの他のコンポーネントと共にWebサイトが展開されている複合UIの例のようなものです。しかし、今はバックエンドの統合サービスで、ユーザーインターフェイスを備えたものではありません。 IT/Opsサービスは実装に直接依存しません。しかし、サービスの実装が必要な場合は、必要なインターフェイスの実装を検索して検索するすべてのコンポーネントをロードします。実装が見つかると、それを実行してデータを取得します。コンポーネントはデータベースに直接移動することもありますが、シンプルでシンプルです。しかし、それはまた、いくつかのREST APIまたはあなたが一番好きなものを介してデータを要求するかもしれません。これは、所有者であるインタフェースを介してこの方法ですべてのデータを収集しますが、他のサービスによって提供される実装です。すべてのデータが収集されると、それは第三者に呼び出され、それが何をすべきかを実行します。
私は、マイクロサービスは、他と通信するためにキューを使用しなければならないと思います。
フロントエンドはコールを生成することができますが、バックエンドはアクションが発生したときに通知を受ける必要のあるロジックを保存する必要があります。
私はRabbitMqがこれらのタイプのデザインにとって素晴らしいツールだと思います。例えば：チェックアウト時
に戻って他の停止を継続承認された場合ので、この流れは、あなたは、コードブロックせずに、一度に多くの段階を更新しても間に負荷を分散することを可能にすることを可能にしますバックエンドサーバー