各マイクロサービスのドメイン モデル境界を識別する

ヒント

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

PDF をダウンロードする

各マイクロサービスのモデルの境界とサイズを特定する場合の目標は、可能な限り細かい分離に到達することではありませんが、可能であれば小さなマイクロサービスに向かう傾向があります。 代わりに、目標は、ドメインの知識に基づく最も意味のある分離に到達することです。 重点はサイズではなく、ビジネス機能に重点を置いています。 さらに、多数の依存関係に基づいてアプリケーションの特定の領域に明確な凝集が必要な場合は、1 つのマイクロサービスも必要であることを示します。 凝集は、マイクロサービスを分離またはグループ化する方法を識別する方法です。 最終的には、ドメインに関するより多くの知識を得る一方で、マイクロサービスのサイズを反復的に調整する必要があります。 適切なサイズを見つけることは、一発のプロセスではありません。

マイクロサービスの認識されるプロモーターであり、書籍「マイクロサービスの構築」の著者である Sam Newman は、前に紹介したように、境界コンテキスト (BC) パターン (ドメイン駆動設計の一部) に基づいてマイクロサービスを設計する必要があることを強調しています。 場合によっては、BC は複数の物理サービスで構成される場合がありますが、その逆は構成できません。

特定のドメイン エンティティを持つドメイン モデルは、具象 BC またはマイクロサービス内で適用されます。 BC は、ドメイン モデルの適用性を区切り、開発者チーム メンバーに、何がまとまりがあり、何を個別に開発できるかを明確かつ共有的に理解できるようにします。 これらはマイクロサービスの目標と同じです。

設計の選択を通知するもう 1 つのツールは 、Conway の法律であり、アプリケーションは、それを生成した組織の社会的境界を反映することを示します。 しかし、会社の組織がソフトウェアによって形成 -the 逆の場合もあります。 コンウェイの法律を逆にし、会社を組織化する方法で境界を構築し、ビジネス プロセスコンサルティングに傾ける必要がある場合があります。

境界付けられたコンテキストを識別するには、 コンテキスト マッピング パターンと呼ばれる DDD パターンを使用できます。 コンテキスト マッピングを使用すると、アプリケーション内のさまざまなコンテキストとその境界を識別できます。 たとえば、小さなサブシステムごとに異なるコンテキストと境界を持つことが一般的です。 コンテキスト マップは、ドメイン間でこれらの境界を定義し、明示的にする方法です。 BC は自律的であり、ドメイン エンティティなどの単一ドメイン -details の詳細が含まれており、他の BC との統合コントラクトを定義します。 これはマイクロサービスの定義に似ています。これは自律的であり、特定のドメイン機能を実装し、インターフェイスを提供する必要があります。 これが、コンテキスト マッピングと境界付きコンテキスト パターンが、マイクロサービスのドメイン モデル境界を識別するための適切なアプローチである理由です。

大規模なアプリケーションを設計する場合、そのドメイン モデルを断片化する方法を確認できます。たとえば、カタログ ドメインのドメイン エキスパートは、カタログ ドメインとインベントリ ドメイン内のエンティティに対して、配送先ドメインのエキスパートとは異なる名前を付けます。 または、顧客に関するすべての詳細を保存する CRM エキスパートを扱う場合、ユーザー ドメイン エンティティのサイズと属性の数が、顧客に関する部分的なデータのみを必要とする注文ドメインエキスパートの場合とは異なる場合があります。 大規模なアプリケーションに関連するすべてのドメインで、すべてのドメイン用語を明確に区別するのは非常に困難です。 しかし、最も重要なことは、用語を統一しようとしてはいけないということです。 代わりに、各ドメインによって提供される違いとリッチさを受け入れます。 アプリケーション全体の統合データベースを作成しようとすると、統一されたボキャブラリの試行は厄介になり、複数のドメインの専門家には正しく聞こえません。 そのため、BCs (マイクロサービスとして実装) は、特定のドメイン用語を使用できる場所と、システムを分割して別のドメインを持つ追加の BC を作成する必要がある場所を明確にするのに役立ちます。

ドメイン モデル間に強い関係がほとんどなく、通常、一般的なアプリケーション操作を実行するときに複数のドメイン モデルの情報をマージする必要がない場合は、各 BC およびドメイン モデルの適切な境界とサイズを取得していることがわかります。

おそらく、各マイクロサービスのドメイン モデルの大きさに関する問題に対する最善の答えは、自律的な BC を可能な限り分離する必要があることです。これにより、他のコンテキスト (他のマイクロサービスのモデル) に絶えず切り替えることなく作業できます。 図 4-10 では、アプリケーションで識別された各ドメインの特定の要件に応じて、複数のマイクロサービス (複数の BC) がそれぞれ独自のモデルを持ち、エンティティを定義する方法を確認できます。

図 4-10 エンティティとマイクロサービス モデルの境界の識別

図 4-10 は、オンライン会議管理システムに関連するサンプル シナリオを示しています。 境界付けられたコンテキストに応じて、同じエンティティが "Users"、"Buyers"、"Payers"、"Customers" と表示されます。 ドメインエキスパートが定義したドメインに基づいて、マイクロサービスとして実装できるいくつかの VC を特定しました。 ご覧のように、Payment マイクロサービスの Payments のように、1 つのマイクロサービス モデルにだけ存在するエンティティがあります。 これらは簡単に実装できます。

ただし、異なる形状を持ち、複数のマイクロサービスから複数のドメイン モデル間で同じ ID を共有するエンティティがある場合もあります。 たとえば、ユーザー エンティティは Conferences Management マイクロサービスで識別されます。 同じ ID を持つ同じユーザーは、Ordering マイクロサービスの Buyers という名前のユーザー、または Payment マイクロサービスの Payer という名前のユーザー、さらには Customer Service マイクロサービス内の Customer という名前のユーザーです。 これは、各ドメインの専門家が使用している ユビキタス言語 によっては、属性が異なる場合でもユーザーの視点が異なる可能性があるためです。 Conferences Management という名前のマイクロサービス モデルのユーザー エンティティには、ほとんどの個人データ属性が含まれる場合があります。 ただし、マイクロサービスの支払いにおける Payer の形の同じユーザー、またはマイクロサービスの Customer の形の同じユーザーは、同じ属性の一覧を必要としない場合があります。

図 4-11 に、同様の方法を示します。

図 4-11 従来のデータ モデルを複数のドメイン モデルに分解する

境界付けられたコンテキスト間で従来のデータ モデルを分解する場合、境界付けられたコンテキストごとに異なる属性を持つ同じ ID (購入者もユーザー) を共有する異なるエンティティを持つことができます。 ユーザーが Conferences Management マイクロサービス モデルにユーザー エンティティとして存在し、価格マイクロサービスの Buyer エンティティの形式で存在し、実際に購入者であるユーザーに関する代替属性または詳細を確認できます。 各マイクロサービスまたは BC は、解決する問題やコンテキストによっては、ユーザー エンティティに関連するすべてのデータを必要とせず、その一部だけを必要とする場合があります。 たとえば、価格マイクロサービス モデルでは、ID (ID) と状態のみであるユーザーのアドレスや名前は必要ありません。これは、購入者ごとのシートの価格設定時に割引に影響します。

Seat エンティティの名前は同じですが、ドメイン モデルごとに属性が異なります。 ただし、シートは、ユーザーと購入者の場合と同じ ID に基づいて ID を共有します。

基本的に、複数のサービス (ドメイン) に存在するユーザーの共有概念があり、そのユーザーの ID はすべて共有されます。 ただし、各ドメイン モデルでは、ユーザー エンティティに関する詳細が追加または異なる場合があります。 そのため、あるドメイン (マイクロサービス) から別のドメインにユーザー エンティティをマップする方法が必要です。

ドメイン間で同じ数の属性を持つ同じユーザー エンティティを共有しないことには、いくつかの利点があります。 1 つの利点は、マイクロサービス モデルに不要なデータが含まれていないように、重複を減らすことです。 もう 1 つの利点は、エンティティごとに特定の種類のデータを所有するプライマリ マイクロサービスを使用して、その種類のデータの更新とクエリがそのマイクロサービスによってのみ実行されるようにすることです。

前へ次へ