前回の記事では、イベント ストームを使用してドメイン モデルを構築する方法を学びました。ドメイン モデルを構築するプロセスでは、集約、エンティティ、コマンド、ドメイン イベントなどの多くのドメイン オブジェクトを抽出します。DDD 階層化アーキテクチャ モデルに従って、標準のマイクロサービス コード モデルが確立され、コード オブジェクトの階層構造とディレクトリ構造が定義されます。
マイクロサービスの設計と実装を完了するには、実際にはその後にドメイン オブジェクトをマイクロサービス コード モデルにマッピングするという別のステップがあります。では、なぜこのステップがそれほど重要なのでしょうか?
DDD は、最初にドメイン モデルを構築し、次にドメイン モデルとマイクロサービスの整合性を確保するためにマイクロサービスを設計することを重視しているため、ドメイン モデルなしではマイクロサービスの設計と実装について語ることはできません。しかし、ドメイン モデルを構築するときは、ビジネスの観点から立つことが多く、一部のドメイン オブジェクトにはビジネス言語も含まれます。また、ドメイン モデルをマイクロサービス設計の入力として使用し、ドメイン オブジェクトを設計して変換し、ドメイン オブジェクトとコード オブジェクト間のマッピング関係を確立する必要もあります。
ドメインオブジェクトの照合
マイクロサービスの分割が完了すると、ドメイン モデルとドメイン オブジェクトの境界が基本的に決まります。
最初の重要な仕事は、イベント ストーム中に生成されるさまざまなドメイン オブジェクト (集約、エンティティ、コマンド、ドメイン イベントなど) を分類し、これらのドメイン オブジェクトとビジネス動作を以下の表に記録することです。
ご覧のとおり、このテーブルにはドメイン モデル、集約、ドメイン オブジェクト、ドメイン タイプの 4 つの側面が含まれています。ドメイン モデルには複数の集約が含まれ、集約には複数のドメイン オブジェクトが含まれます。各ドメイン オブジェクトには独自のドメイン タイプがあります。ドメイン タイプは主に、集約ルート、エンティティ、コマンド、ドメイン イベントなどのドメイン オブジェクトの属性を識別します。
ドメインモデルからマイクロサービス設計まで
ドメイン モデルからマイクロサービスの実装に至るまで、さらに設計と分析を行う必要があります。イベント ストームから抽出されたドメイン オブジェクトは、マイクロサービス システムの開発で使用する前に、ユーザー ストーリーまたはドメイン ストーリー、およびマイクロサービス設計によって分析する必要があります。
このプロセスは、イベント ストームよりも詳細かつ詳細になります。主な懸念事項は次のとおりです。
- マイクロサービス内にどのようなサービスがあるかを分析しますか?
- サービスはどの層に存在しますか?
- アプリケーション サービスによって構成および調整されるサービスは何ですか?
- ドメイン サービスにはどのエンティティのビジネス ロジックが含まれていますか?
- 輻輳モデルを採用するエンティティのプロパティとメソッドは何ですか?
- どのような値のオブジェクトがありますか?
- どのエンティティが集約ルートなどですか?
- 最後に、すべてのドメイン オブジェクトとその依存関係を整理し、各ドメイン オブジェクトに対応するコード オブジェクトを設計し、それらのソフトウェア パッケージとコード ディレクトリを定義します。
この設計プロセスで推奨される役割は、DDD スペシャリスト、アーキテクト、デザイナー、開発マネージャーです。
ドメインオブジェクト
イベント ストームの終わりには、通常、ドメイン モデル集合体にドメイン オブジェクト (集合体、エンティティ、コマンド、およびドメイン イベント) が存在します。ストーリー分析とマイクロサービスの設計が完了すると、通常、マイクロサービスの集合体には、集合体、集合体ルート、エンティティ、値オブジェクト、ドメイン イベント、ドメイン サービス、ストレージなどのドメイン オブジェクトが存在します。
これらのドメイン オブジェクトがどのように取得されるかを見てみましょう。
1. 設計主体
ほとんどの場合、ドメイン モデルのビジネス エンティティとマイクロサービスのデータベース エンティティの間には 1 対 1 の対応関係があります。ただし、一部のドメイン モデル エンティティは、マイクロサービスの設計中に複数のデータ エンティティとして設計される場合や、エンティティの一部の属性が値オブジェクトとして設計される場合があります。
個々の顧客を分析する場合、住所、電話番号、銀行口座番号などのエンティティも必要です。これらは集約ルートによって参照され、ドメイン モデリング中に見つけるのは簡単ではありません。マイクロサービス設計プロセス中にこれらを特定して設計する必要があります。 。
階層化アーキテクチャでは、エンティティは輻輳モデルを採用し、エンティティのすべてのビジネス ロジックはエンティティ クラスに実装されます。これらのさまざまなエンティティには独自のメソッドとビジネス動作があります。たとえば、住所エンティティには住所を追加および変更するメソッドがあり、銀行口座エンティティには銀行口座番号を追加および変更するメソッドがあります。
エンティティ クラスは、ドメイン層のエンティティ ディレクトリ構造の下に配置されます。
2. 集約ルートを見つける
集約ルートはドメイン モデルに由来しており、個別顧客の集約では、個別の顧客エンティティが集約ルートとなり、住所、電話番号、銀行口座番号のライフ サイクルの管理を担当します。個々の顧客の集約ルートは、ファクトリ モードとストレージ モードを通じて、集約内の住所や銀行口座番号などのエンティティおよび値オブジェクト データの初期化と永続化を実装します。
集約ルートは、独自のプロパティとメソッドを持つ特別な種類のエンティティです。集約ルートは集約間のオブジェクト参照を実装でき、集約内のすべてのエンティティを参照することもできます。集約ルート クラスは、コード モデルのエンティティ ディレクトリ構造の下に配置されます。集約ルートには、顧客コードの生成、顧客情報の追加および変更などの独自の実装メソッドがあります。
3. 設計値オブジェクト
必要に応じて、特定のエンティティの特定のプロパティまたはプロパティ セットを値オブジェクトとして設計します。値オブジェクト クラスは、コード モデルのエンティティ ディレクトリ構造の下に配置されます。個別顧客集約では、顧客は顧客証明書タイプを持っており、これは列挙値の形式で存在するため、値オブジェクトとして設計されています。
一部のドメイン オブジェクトは値オブジェクトまたはエンティティとして設計できるため、特定の状況に応じてそれらを分析する必要があります。このドメイン オブジェクトが他の集合体のライフ サイクルを維持し、接続されているエンティティ オブジェクト内でのみ全体の置換を許可する場合は、それを値オブジェクトとして設計できます。このオブジェクトに複数の項目があり、それに基づいてクエリ統計を作成する必要がある場合は、それをエンティティとして設計することをお勧めします。
4. デザインフィールドイベント
ドメイン モデル内のドメイン イベントが次のビジネス オペレーションをトリガーする場合は、ドメイン イベントを設計する必要があります。まず、ドメイン イベントがマイクロサービス内で発生するかマイクロサービス間で発生するかを判断します。次に、イベント エンティティ オブジェクト、イベントのパブリッシュおよびサブスクライブ メカニズム、およびイベントの処理メカニズムを設計します。イベントバスとメッセージミドルウェアのどちらを導入するかを決定します。
Personal Customer 集計には、顧客が作成されたドメイン イベントがあるため、Customer Created Event というエンティティがあります。
ドメイン イベント エンティティと処理クラスは、ドメイン層のイベント ディレクトリ構造の下に配置されます。ドメイン イベントのパブリッシュ クラスとサブスクライブ クラスをアプリケーション層のイベント ディレクトリ構造の下に配置することをお勧めします。
5. デザイン分野のサービス
ビジネスのアクションや動作が複数のエンティティにまたがる場合は、ドメイン サービスを設計する必要があります。ドメイン サービスは、複数のエンティティとエンティティ メソッドを組み合わせることによって、コア ビジネス ロジックを完成させます。ドメイン サービスは、エンティティ メソッドの上、アプリケーション サービスの下にあるビジネス ロジックの層と考えることができます。
厳密な階層化アーキテクチャ層の依存関係に従って、エンティティのメソッドをアプリケーション層に公開する必要がある場合、アプリケーション サービスから呼び出す前に、そのメソッドをドメイン サービスにカプセル化する必要があります。したがって、フロントエンド アプリケーションによってエンティティ メソッドを呼び出す必要がある場合は、それをドメイン サービスにカプセル化してから、アプリケーション サービスにカプセル化します。
個別顧客集約ルートエンティティによる個人顧客情報の作成方法は、個人顧客情報ドメインサービスの作成としてカプセル化されています。次に、これをパッケージ化して個人顧客情報アプリケーション サービスを作成し、フロントエンド アプリケーションに公開します。
ドメイン サービス クラスは、ドメイン層のサービス ディレクトリ構造の下に配置されます。
6. デザインストレージ
各集約にはウェアハウスがあり、主にデータ クエリと永続化操作を完了するために使用されます。ウェアハウスにはウェアハウス インターフェイスとウェアハウス実装が含まれており、依存関係の逆転を通じてアプリケーション ビジネス ロジックとデータベース リソース ロジックの分離を実現します。
ストレージ コードは、ドメイン層のリポジトリ ディレクトリ構造の下に配置されます。
アプリケーション層のドメインオブジェクト
アプリケーション層の主なドメイン オブジェクトは、アプリケーション サービスとイベントのパブリケーションとサブスクリプションです。
イベント ストームやドメイン ストーリーの分析では、ユーザーやシステムによって開始されたコマンドに基づいてサービスやエンティティ メソッドを設計することがよくあります。このコマンドに応答して、以下を解析してログに記録する必要があります。
- アプリケーション層とドメイン層でどのようなビジネス動作が発生するか。
- 各層に対してどのサービスまたはメソッドを設計する必要があるか。
- これらのメソッド、サービス、およびドメイン タイプ (エンティティ メソッド、ドメイン サービス、アプリケーション サービスなど) の階層化、それらの間の呼び出しと構成の依存関係。
厳密な階層化アーキテクチャ モードでは、サービスのクロスレイヤー呼び出しは許可されず、各サービスは次のレイヤーのサービスのみを呼び出すことができます。サービスは下から上に、エンティティ メソッド、ドメイン サービス、アプリケーション サービスです。サービスのクロスレイヤー呼び出しを実装する必要がある場合はどうすればよいでしょうか? サービスのレイヤーごとのカプセル化アプローチを採用することをお勧めします。
上の図を見てみましょう. サービスをカプセル化して呼び出す方法は主に次のとおりです。
1. エンティティメソッドのカプセル化
エンティティ メソッドは、最下位のアトミックなビジネス ロジックです。単一エンティティのメソッドを複数の層にわたって呼び出す必要がある場合は、それをドメイン サービスにカプセル化して、カプセル化されたドメイン サービスをアプリケーション サービスによって呼び出して調整できるようにします。ユーザー インターフェイス層によって呼び出す必要がある場合は、このドメイン サービスをアプリケーション サービスとしてカプセル化する必要もあります。レイヤーごとのサービスのカプセル化後、エンティティ メソッドを上位のさまざまなレイヤーに公開して、レイヤー間の呼び出しを実現できます。
カプセル化する場合、サービスの前の名前は同じままにすることができ、*DomainService または *AppService サフィックスを使用してドメイン サービスとアプリケーション サービスを区別できます。
2. ドメインサービスの組み合わせとカプセル化
ドメイン サービスは、アプリケーション サービス呼び出し用の複数のエンティティとエンティティ メソッドを組み合わせて調整します。ユーザー インターフェイス層に公開する必要がある場合、ドメイン サービスをアプリケーション サービスとしてカプセル化する必要があります。
3. アプリケーションサービスの構成とオーケストレーション
アプリケーション サービスは、複数のドメイン内のサービスを組み合わせて調整し、フロントエンド アプリケーション呼び出し用のユーザー インターフェイス層にサービスを公開します。
アプリケーション サービスを構成および調整するときは、複数のアプリケーション サービスが同じドメイン内の複数のサービスに対して同じビジネス ロジックを繰り返し組み合わせて調整する可能性があるという現象に注意する必要があります。このような場合は、ドメイン サービスを統合できるかどうかを分析する必要があります。繰り返し組み合わされるこれらのドメイン サービスを 1 つのドメイン サービスに結合して実装できます。これにより、アプリケーション サービスの繰り返しのオーケストレーションが不要になるだけでなく、サービスの進化も実現します。このようにして、ドメイン モデルはますます洗練され、ビジネス要件によりよく適応できるようになります。
アプリケーション サービス クラスは、アプリケーション層のサービス ディレクトリ構造の下に配置されます。ドメイン イベントのパブリッシュ クラスとサブスクライブ クラスは、アプリケーション層のイベント ディレクトリ構造の下に配置されます。
ドメイン オブジェクトとマイクロサービス コード オブジェクト間のマッピング
上記の分析と設計が完了すると、次の図に示すように、ドメイン オブジェクトとマイクロサービス コード オブジェクトの間のマッピング関係を確立できます。
典型的なドメインモデル
個人顧客ドメイン モデルにおける個人顧客の集約は典型的なドメイン モデルであり、そこから複数のエンティティと値オブジェクト、およびその集約ルートを抽出できます。下の図を見てみましょう。個人顧客の集計をさらに分析しました。個人顧客フォームの集約ルートが抽出され、顧客タイプ値オブジェクト、電話番号、住所、銀行口座番号などのエンティティが形成されます。カプセル化と階層化は、エンティティのメソッドとサービス、およびドメイン オブジェクトの関連付けと依存関係に対して実行されます。収納やその他のデザインを確立しています。重要なのはこのプロセスであり、ドメイン オブジェクトとマイクロサービス コード オブジェクトの間のマッピング関係を確立しました。
以下に、表の各列について簡単に説明します。
- レイヤ: インターフェイス層、アプリケーション層、ドメイン層、ベース層など、層状アーキテクチャ内でドメイン オブジェクトが配置される層を定義します。
- ドメイン オブジェクト: ドメイン モデル内のドメイン オブジェクトの特定の名前。
- ドメイン タイプ: DDD ナレッジ システムに従って定義されたドメイン オブジェクトのタイプ。これには、有界コンテキスト、集約、集約ルート、エンティティ、値オブジェクト、ドメイン イベント、アプリケーション サービス、ドメイン サービス、ストレージ サービス、およびその他のドメイン タイプが含まれます。
- 依存ドメイン オブジェクト: ビジネス オブジェクトまたは階層呼び出しの依存関係に従って、サービス コールの依存関係、関連オブジェクトの集約などのドメイン オブジェクトの依存関係が確立されます。
- パッケージ名: コード モデル内のパッケージ名。ドメイン オブジェクトが配置されているパッケージに対応します。
- クラス名: コード モデル内のクラス名。ドメイン オブジェクトのクラス名に対応します。
- メソッド名: コード モデル内のメソッド名。ドメイン オブジェクトの実装または操作のメソッド名に対応します。
このマッピング関係を確立すると、次の図に示すようなマイクロサービスのコード構造を取得できます。
非典型的なドメインモデル
一部のビジネス シナリオは希望どおりにならない場合があり、一般的なドメイン モデルを設計できない場合があります。このタイプのビジネスには複数のエンティティがあり、エンティティは互いに独立しており、疎結合の関係にあります。これらのエンティティは主に分析または計算に関与します。集約ルートを見つけることはできませんが、高度に結合しています。ビジネスそのものの。そして、それらが結合するビジネスとその他の集合体は、限定されたコンテキスト内にあり、それを単独のマイクロサービスとして設計する可能性はほとんどありません。
この種のビジネス シナリオは実際には非常に一般的です。たとえば、個人顧客ドメイン モデルには顧客の統合の集約があり、すべての顧客をスキャンし、ID 番号や電話番号などのビジネス ルールに従って重複顧客かどうかを判断し、重複する顧客を統合します。
このビジネス シナリオでは集約ルートが見つかりません。
では、このような非典型的なモデルをどうすればよいのでしょうか? 私たちは依然として集約の考え方から学び、機能のこの部分を定義するために集約を使用し、エンティティの属性とメソッドを確立し、メソッドとサービスをカプセル化し、階層的に設計するために典型的なドメイン モデルと同じ分析方法を使用します。 、ストレージを設計し、ドメイン オブジェクト間の依存関係を確立します。唯一の残念な点は、まだ集約ルートが見つからないことですが、集約ルート管理機能に加えて、DDD の他の設計方法も使用できるため、問題はありません。
要約する
この記事では、マイクロサービスの設計プロセスにおいて非常に重要である、ドメイン モデルからマイクロサービスまでの設計プロセスについて説明します。マイクロサービス システムの観点から見ると、ドメイン モデルを徹底的かつ詳細に分析し、ドメイン オブジェクトを階層化し、各ドメイン オブジェクトの依存関係を見つけて、ドメイン オブジェクトとマイクロサービスの間のマッピング関係を確立する必要があります。コード オブジェクトを使用してドメイン モデルを保証し、コード モデルとの整合性を確保することで、最終的にマイクロサービスの設計が完了します。
ビジネスモデルとマイクロサービスシステムアーキテクチャの関係を確立した後は、プロジェクトチーム全体が統一された共通言語の下で作業できるため、ビジネスに詳しくない開発者やコードに詳しくない業務担当者でも、コードの場所をすぐに見つけることができます。 。