ビジネスロジックはマイクロサービスアーキテクチャのどこに配置する必要がありますか？

私はモノリシックなアプローチに慣れているので、マイクロサービスアーキテクチャに頭を抱えようとしています。

非常に簡素化された Uber予約システムを構築しようとしているとします。：物事を単純化するために、我々は、我々は3つのサービスとクライアントのゲートウェイAPIを持っているとしましょうBooking、Drivers、Notificationと私たちは、次のワークフローを持っています：

新しい予約を作成する場合：

1. 既存のユーザーがすでに予約しているかどうかを確認する
2. 利用可能なドライバーのリストを取得する
3. ドライバーに通知を送信して予約を受け取ります
4. 運転手が予約をピックアップ

すべてのメッセージングがkafkaのようなメッセージングバスではなくhttp呼び出しを介して行われるとしましょう。

したがって、この場合、Bookingサービスは既存の予約の確認を行うことができると思いました。しかし、利用可能なドライバーと通知のリストを誰が取得する必要がありますか？ゲートウェイレベルで実行することを考えていますが、ロジックは次の2つの場所に分割されています。

• Gateway -利用可能なドライバーのリストを取得+通知を送信
• Booking -既存の予約を確認する

そして、ゲートウェイはそれを行うのに適切な場所ではないと確信していますが、Bookingサービスでそれを行っている場合、緊密に結合されているように感じますか？

さらに複雑にするために、予約システムを再利用したいが、独自のビジネスロジックを追加した別のプロジェクトがある場合はどうなるでしょうか。新しいプロジェクトゲートウェイが独自のビジネスロジックを既存のものから分離できるように、ゲートウェイレベルでそれを行うことを考えたのはそのためです。

それを行う別の方法は、各プロジェクトがコア予約サービスと通信する独自​​の予約サービスを持っていることですが、ここでの最善のアプローチは何なのかわかりません:-)

人々はしばしば「マイクロサービス」を聞いて「ナノサービス」を考えます、そしてこれはいくつかの混乱を引き起こす可能性があります。これらはマイクロサービスであるため、エンティティごとに個別のサービスは必要ありません。あなたがやろうとしていることはすべてbookingとnotificationサービスにあるべきです。driverサービスは必要ありません（説明したアクティビティのいずれか）。

予約可能なドライバーのリストを取得することは、このbookingサービスに該当します。一般的な落とし穴は、関連するアクティビティを同じサービスにグループ化しないことです。これは低コヒーレンスと呼ばれ、非常に悪いです。エンティティごとではなく、問題ドメインごとにサービスにグループ化することを忘れないでください。

さて、再利用に関しては、個別のマイクロサービスを持つことの利点は、消費者向けアプリを作成する3つの個別のチームを持つことができるようになったことです。標準のHTML Webアプリ、Androidアプリ、iOSアプリの1つのチーム。これらのさまざまなアプリケーションはすべてまったく異なる方法で構築でき、特定のプラットフォームに適切に見えます（コードを繰り返す必要はありません）。bookingすべての3つのアプリケーションがHTTPではなく、自分の予約コードを有するサービスへの呼び出しを行うため、サービスコードは、これらのアプリケーションのすべての3つによって再利用されます。

一般的な予約フローは次のようになります。

1. Androidアプリがbookingサービスを呼び出して、利用可能なドライバーのリストを取得します
2. 予約サービスはドライバーのリストをアプリに返します
3. 次に、ユーザーはドライバーを選択し、アプリはbookingサービスの「book」メソッドを呼び出します
4. bookingサービスのサービスコールnotification予約の詳細とサービスを
5. notificationサービスは、予約の彼を通知し、ドライバーに通知を送信します
6. ドライバーアプリnotificationは、顧客から1マイル以内にいるときにサービスにメッセージを送信します
7. notificationサービスは、そのドライバーは、ほとんどがあることを顧客にアラートを送信します

これがお役に立てば幸いです。それらはナノサービスではなくマイクロサービスであることを忘れないでください。同じ問題ドメインを分割しようとしないでください。したがって、質問のタイトルに答えるために、マイクロサービスを適切なサイズに保つと、その問題ドメインのビジネスロジックのすべて、またはほとんどが、そのマイクロサービス内に存在できます。

それはすべてあなたの正確な要件に依存します。

予約を行う2つのアプリケーションがあるとします。

1. 最初のケース：1つのアプリケーションで1人のユーザーが複数回予約できるようにし、もう1つのアプリケーションでは1人だけが予約できるようにします。これは、予約の制限がアプリケーションレベルにあることを意味します。たとえば、予約システムに2つのエントリポイントがある（1つは複数予約を許可し、もう1つは許可しない）か、関連するマイクロサービスでそれをチェックするだけです。応用。
2. 2番目のケース：アプリケーションが何であれ、ユーザーが複数のものを持つことができないのは「予約」の定義の一部です。このルールはシステム全体に当てはまります。つまり、予約マイクロサービスにチェックを入れることができます。

通知システムに関しては、マイクロサービスに予約サービスをサブスクライブさせて、新しい予約をリッスンすることができます。そのため、予約マイクロサービスはすべての加入者に通知し、それに応じて行動します。

この種類のアーキテクチャの唯一の問題は、通知が公開された後に何かが失敗した場合にどうなるかです。2つのマイクロサービスは、同じデータベーストランザクションで実行される2つの関数のように機能しないため、エラーを適切に処理し、最終的にプロセスを再生する必要があります。失敗した（自動または手動）

簡単な答えは、マイクロサービスのクライアントが「純粋な」マイクロサービスアーキテクチャでビジネスロジックを管理することです。理解を容易にするために、さらに単純な例を検討してください。URIに基づいてバイトのストリームを返すだけのサービス。それ自体は、それほど有用ではありません。どのURIに何が含まれているかを何らかの方法で把握していなければ、どこからプルするかを推測することしかできません。次に、検索機能を提供する別のマイクロサービスがあるとします。クエリ文字列を含むリクエストを送信すると、URIが返されます。今、物事はより面白くなります。最初のサービスのURIへの参照をインデックスに入れることができます。

しかし、それでも、これらの2つを何らかの形で調整する必要があります。簡単な答えがあります。ブラウザを使用してインデックスサービスからURIを取得し、データサービスからデータを取得します。どちらのサービスも他のサービスを「認識」しておらず、それらの間には絶対的な結合はありません。他のデータサービスでインデックスサービスを使用でき、その逆も可能です。

これがすべてのシナリオで最良のアプローチであるとは限りませんが、この方法で物事を構築することには多くの利点があり、特に現在知られていないシナリオでの再利用性があります。