web-dev-qa-db-ja.com

Web APIのマイクロサービス設計パーツ

こんにちは私はプロジェクトスケルトンを使用しようとしています [〜＃〜] cqrs [〜＃〜] パターンといくつかの外部サービスを使用しています。以下は、ソリューションの構造です。

  • WebApi
  • クエリハンドラー
  • コマンドハンドラー
  • リポジトリー
  • ApiGateways（ここにマイクロサービス呼び出しのインターフェースと実装があります）

コントローラーを薄く保つ必要があります。したがって、それぞれの操作を処理するためにクエリハンドラーとコマンドハンドラーを使用しています。

enter image description here ただし、外部のマイクロサービスを使用して、クエリハンドラーから呼び出しているデータを取得します。すべてのhttp clinet構築と呼び出しがそれらで抽象化されます。応答はビューモデルに変換され、クエリハンドラーに渡されます。

ApiGateways と名付けます。ただし、複数のサービスから構成されているわけではありません。私たちのソリューションでは、この部分をどのように呼びますか？プロキシか何か？シンコントローラーとマイクロサービスアーキテクチャの良い例

c#design-patternsarchitecturemicroservicescqrs
4
Developer

CQRSは、読み取り操作と書き込み操作を分離しておくための正しい選択だと思います。

サードパーティシステムとの統合（そうである場合）には、注意が必要です。これらのサービスをハンドラーから直接呼び出さないでください。これにより、さまざまなパフォーマンスやメンテナンス性の問題が発生する可能性があります。

これらの統合はドメイン外にあるため、非常によく分離する必要があります。それらは、非効率、変更、または制御不能な多くの問題の影響を受ける可能性があります。

私がお勧めできるソリューションの1つは、「ミドルウェア」サービスです。

アプリケーションのコンテキストでは、これは別のサービス（常にRESTなど））で構成でき、単一システムの統合ポイントとして機能する、外部システムとの（彼のみ）のタスクを実行しますドメインと外部環境の間。これは、ゼロから、または（例として） this のような商用/オープンソースソリューションを使用して実現できます。

これにより、次のような多くの利点がもたらされます。

  • ミドルウェアは、アプリケーションの統合テスト中のユニークな模造ポイントです。
  • ハンドラーに手を加えることなく、ミドルウェアの実装を将来変更することができます。
  • もちろん、3ptyプロバイダーを変更してもドメインサービスには影響しません。
  • ミドルウェアは、3ptyサービスの中断の管理に特化した独自のポイントです。
  • あなたのサービスは外の世界と比較して不可知論のままです。

これらの質問に焦点を合わせると、統合ミドルウェアサービスを設計するのに役立ちます。

  • 彼らはどのタイプの3ptyデータを提供していますか？時間通りですか？これは、統合サービスにキャッシュシステムを導入するかどうかを判断するのに役立つ場合があります。
  • 3ptyは頻繁に中断される可能性がありますか？次に、システムが外部サービスの中断に耐えることを確認する必要があります。つまり、サービスの特定の回復力を確保する必要があります。それを行うには テクニック がたくさんあります。
  • 本当にこれらの3ptyサービスに常に問い合わせる必要がありますか？多分多かれ少なかれ洗練されたキャッシュシステムはあなたのサービスを大幅にスピードアップするでしょう。

最後に、マイクロサービス指向のシステムの必要性が現実的かつ緊急の必要性であるかどうかを理解することも非常に重要です。これらのアーキテクチャは従来のアーキテクチャよりも高価で複雑なため、モノリスシステムを構築してから、後でよりセグメント化されたソリューションに移行することを検討するのが妥当かもしれません。システムをいくつもの " bounded context "と考える（整理する）ことは、優れたモノリスシステムの作成を妨げることはありません。同時に、マイクロサービス指向のシステムへの切り替えの準備をします。

まとめのアドバイスとして、まず物事をできるだけ分離することから始めます。 言語 を定義して、ビジネスモデルについて話します。これらは、必然的にソフトウェアの進化の間に必然的に多大な努力を必要としないときに、多くの変化をもたらす可能性があります。 " Hexagonal "アーキテクチャは、両方の選択肢（マイクロサービスとモノリス）でそれを行うための良い出発点です。最近、Netflixがこのアーキテクチャについて素晴らしい article を投稿しました。

1
Matteo Tosato

DDDとクリーンアーキテクチャの観点から、私の答えを示します。理想的には、アプリケーションには次のレイヤーが必要です。

  1. Api（理想的にはコントローラーの非常に薄い層）。コントローラーはクエリとコマンドを作成し、共通のチャネルにプッシュします。 （参照 MediatR ）
  2. Applicationこれはオーケストレーションレイヤーになります。クエリとコマンドの定義とそのハンドラーが含まれます。クエリの場合は、インフラストラクチャレイヤーから直接対話します。コマンドの場合は、ドメインを操作し、インフラストラクチャのリポジトリを介して保存します。
  3. Domainビジネスロジックと複雑さに応じて、このレイヤにはすべてのビジネスモデルが含まれます。
  4. インフラストラクチャほとんどの場合、2種類のオブジェクトProvidersとリポジトリ。プロバイダーはクエリで使用する必要があり、DAOを返します。リポジトリは、ドメインが関係する場所、理想的にはCQRSのコマンドで使用する必要があります。リポジトリは常にドメインオブジェクトのみを受信して​​返す必要があります。

そのため、クリーンアーキテクチャ上のさまざまなレイヤーに関する基本コンテキストを設定した後、元の質問に対する答えは->プロバイダーレイヤーでサードパーティの相互作用を作成します。たとえば、ユーザーマイクロサービスに接続する必要がある場合は、インフラストラクチャレイヤーのプロバイダーフォルダーにUserProviderを作成し、インターフェイスを介して使用します。

0
Rahul Garg