次の方法で共有

eShopOnContainers の DDD マイクロサービスに CQRS と CQS のアプローチを適用する

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

PDF をダウンロードする

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

eShopOnContainers 参照アプリケーションでの注文マイクロサービスの設計は、CQRS の原則に基づいています。 ただし、クエリをコマンドから分離し、両方のアクションに同じデータベースを使用するだけの最も簡単な方法を使用します。

これらのパターンの本質、そしてここで重要なのは、クエリが冪等であることです。システムに何度クエリを実行しても、そのシステムの状態は変わりません。 言い換えると、クエリには副作用がありません。

したがって、注文マイクロサービスが同じデータベースを使用している場合でも、トランザクション ロジック "書き込み" ドメイン モデルとは異なる "読み取り" データ モデルを使用できます。 そのため、これは簡略化された CQRS アプローチです。

一方、トランザクションとデータ更新をトリガーするコマンドは、システムの状態を変更します。 コマンドを使用する場合は、複雑さと絶えず変化するビジネス ルールに対処する際に注意する必要があります。 ここでは、DDD 手法を適用して、より優れたモデル化されたシステムを実現します。

このガイドで示されている DDD パターンは、汎用に適用しないでください。 これにより、設計に制約が生じます。 これらの制約は、特にシステムの状態を変更するコマンドやその他のコードにおいて、時間の経過に伴う品質の向上などの利点を提供します。 ただし、これらの制約により複雑さが増し、データの読み取りとクエリの利点が少なくなります。

このようなパターンの 1 つは集計パターンです。これについては、後のセクションで詳しく説明します。 簡単に言うと、集計パターンでは、ドメイン内のリレーションシップの結果として、多くのドメイン オブジェクトを 1 つの単位として扱います。 クエリでは、このパターンから常に利点が得られるとは限りません。クエリ ロジックの複雑さが増す可能性があります。 読み取り専用クエリの場合、複数のオブジェクトを 1 つの集計として扱う利点はありません。 手に入るのは複雑さだけです。

前のセクションの図 7-2 に示すように、このガイドでは、(つまり、コマンドによってトリガーされる) マイクロサービスのトランザクション/更新領域でのみ DDD パターンを使用することを提案します。 クエリは、より単純なアプローチに従うことができるので、CQRS アプローチに従ってコマンドから分離する必要があります。

"クエリ側" を実装する場合は、EF Core、AutoMapper プロジェクション、ストアド プロシージャ、ビュー、具体化されたビュー、マイクロ ORM などの本格的な ORM から、多くのアプローチから選択できます。

このガイドと eShopOnContainers (具体的には注文マイクロサービス) では、 Dapper のようなマイクロ ORM を使用してストレート クエリを実装することを選択しました。 このガイドでは、オーバーヘッドが少ない軽いフレームワークのおかげで、SQL ステートメントに基づいてクエリを実装して最高のパフォーマンスを得ることができます。

この方法を使用する場合、エンティティを SQL データベースに永続化する方法に影響を与えるモデルの更新には、Dapper で使用される SQL クエリに対する個別の更新や、クエリに対するその他の個別の (EF 以外の) アプローチも必要です。

CQRS および DDD パターンは最上位のアーキテクチャではありません

CQRS とほとんどの DDD パターン (DDD レイヤーや集計を含むドメイン モデルなど) はアーキテクチャ スタイルではなく、アーキテクチャ パターンのみであることを理解しておくことが重要です。 マイクロサービス、SOA、およびイベント ドリブン アーキテクチャ (EDA) はアーキテクチャ スタイルの例です。 多くのマイクロサービスなど、多くのコンポーネントのシステムについて説明します。 CQRS および DDD パターンは、単一のシステムまたはコンポーネント内の何かを表します。この場合は、マイクロサービス内の何か。

境界付けられたコンテキスト (BC) は、異なるパターンを使用します。 彼らは異なる責任を持っており、それは異なる解決策につながります。 どこでも同じパターンを強制すると失敗につながることを強調する価値があります。 CQRS および DDD パターンはどこでも使用しないでください。 多くのサブシステム、BC、またはマイクロサービスはよりシンプルであり、単純な CRUD サービスまたは別のアプローチを使用して、より簡単に実装できます。

アプリケーション アーキテクチャは、設計するシステムまたはエンド ツー エンド アプリケーションのアーキテクチャ (マイクロサービス アーキテクチャなど) の 1 つだけです。 ただし、そのアプリケーション内の各境界コンテキストまたはマイクロサービスの設計には、アーキテクチャ パターン レベルでの独自のトレードオフと内部設計の決定が反映されます。 CQRS や DDD と同じアーキテクチャ パターンをどこでも適用しないでください。

その他のリソース

前へ次へ