DDD の設計プロセスをより深く理解するために、この記事ではプロジェクトを使用して DDD の戦略的設計と戦術的設計を理解し、ドメイン モデリングからマイクロサービス設計までのプロセス全体を確認し、DDD の主要な設計プロセスを習得します。 DDD の概要と重要なポイント。
プロジェクトの基本情報
プロジェクトの目標は、オンラインでの休暇・勤怠管理の実現です。機能の説明は次のとおりです。
- 休暇申請者は、休暇申請書に必要事項を記入して承認を求め、申請者の本人確認、休暇の種類、休暇日数などを確認し、承認規定に基づき承認を受けます。承認を得るために段階的に上司に提出されます。
- 勤怠ルールに従って、休暇データが消失した後、勤怠データが検証され、勤怠統計が出力されます。
戦略的デザイン
戦略的設計は、ユーザー ジャーニー分析に基づいてドメイン オブジェクトと集約ルートを見つけ、エンティティと値オブジェクトをクラスタリングして集約を形成し、境界のあるコンテキストを分割し、ドメイン モデルを確立するプロセスです。
戦略設計で使用される手法はイベント ストームであり、製品ビジョン、シナリオ分析、ドメイン モデリング、マイクロサービス分割などのいくつかの主要プロセスが含まれます。
戦略的設計フェーズで推奨される参加者: ドメインの専門家、ビジネス要求者、製品マネージャー、アーキテクト、プロジェクト マネージャー、開発マネージャー、およびテスト マネージャー。
1. 製品ビジョン
製品ビジョンとは、製品のトップレベルの価値を設計し、製品のターゲットユーザー、コアバリュー、差別化された競合ポイントなどについて合意を形成し、製品の方向性が逸脱しないようにすることです。イベントの嵐の中、参加者全員がポイントごとにシールに意見を書き、ホワイトボードに掲示しました。イベントストームの主催者は各ステッカーについて話し合い、多様な意見を収束・統一して以下の製品ビジョンマップを形成します。
私たちは、この製品ビジョン マップを 1 つの段落にまとめました。社内および社外の従業員、オンライン休暇、自動勤怠統計、社外人事管理のニーズを満たすために、当社はこのオンライン休暇勤怠システムを構築しました。自動的に出席統計を取得します。社内人材のみを管理しイントラネット上でのみ利用できる人事システムとは異なり、社内と社外のネットワークで同時に休暇申請を行うことができ、社内外の担当者を管理して休暇申請や定期的な勤怠分析を行うことができます。当社の製品は社内ネットワークと社外ネットワークの両方で使用できるため、社内と社外の担当者を区別なく管理できます。
製品ビジョン分析を通じて、プロジェクト チームはシステム名をオンライン休暇勤怠システムに統一し、プロジェクトの目標と主要機能、競合製品 (HR) との主な違い、独自の利点と核となる競争力を明確にしました。
製品ビジョン分析は、スタートアップシステムにとって、システム構築の焦点を明確にし、チーム構築の目標を統一し、共通言語を確立するために非常に価値があります。ただし、システムの目標と要件が非常に明確である場合は、この手順は無視できます。
2. シナリオ分析
シナリオ分析では、ユーザーの観点からビジネス ドメインの典型的なシナリオを調査し、ドメイン モデリングをサポートするために、ドメイン内でサポートする必要があるシナリオの分類、ユース ケースの操作、およびさまざまなサブドメイン間の依存関係を生成します。
プロジェクト チームのメンバーは協力して、イベント ストーミングを使用して、休暇と出席に関するユーザー ジャーニーを分析します。さまざまな役割の行程とシナリオ分析に従って、フロントエンド操作からバックエンド ビジネス ロジックに至るすべての操作、コマンド、ドメイン イベント、および外部依存関係を可能な限り包括的に整理します。
以下では、休暇と人事を求める2つのシナリオを例に挙げて説明します。
最初のシーン: 出発
ユーザー: 放置者
- 休暇取得者ログインシステム：権限マイクロサービスから休暇取得者情報と許可データを取得し、ログイン認証を完了します。
- 休暇フォームを作成する: 休暇ページを開き、休暇の種類と開始時刻を選択し、休暇情報を入力します。休暇申請フォームを保存して作成し、承認を得るために休暇申請を送信します。
- 休暇フォームを変更する: 休暇フォームをクエリし、休暇ページを開き、休暇フォームを変更して、承認のために休暇を送信します。
- 承認のために送信: 承認ルールを取得し、承認ルールに従って人事組織関係から承認者を取得し、承認者を休暇フォームに割り当てます。
2 番目のシナリオ: 承認
ユーザー: 承認者
- 承認者ログインシステム：権限マイクロサービスから承認者情報と権限データを取得し、ログイン認証を完了します。
- 休暇申請フォームの取得: 承認者の名前で休暇申請フォームを取得し、休暇申請フォームを選択します。
- 承認: 承認コメントを入力します。
- レベル別の承認: 上司による承認が必要な場合は、承認ルールに従って、人事組織関係から承認者が取得され、その承認者が休暇フォームに割り当てられます。上記の 4 つの手順を繰り返します。
- 最終承認者が承認を完了します。
承認が完了すると、「承認を離れる」フィールドのイベントが生成されます。フォローアップにはさらに 2 つのビジネス オペレーションがあります: 休暇申請が承認されたという通知を送信し、通知電子メール システムを通じて休暇申請者に通知する; 確認のために休暇申請データを勤怠に送信します。
下図は人事組織関係シーンの分析結果であり、詳細な分析プロセスや勤怠のシーン分析については説明を省略します。
3. ドメインモデリング
ドメインモデリングとは、ビジネスドメインと問題ドメインを分析してドメインモデルを確立することです。境界のあるコンテキストを通じてマイクロサービス境界設計を上方向に導き、集約を通じてエンティティ オブジェクト設計を下方向に導きます。
ドメイン モデリングは集中的なプロセスであり、次の 3 つのステップに分かれています。
- 最初のステップは、ドメイン エンティティや値オブジェクトなどのドメイン オブジェクトを見つけることです。
- 2 番目のステップは、集約ルートを見つけて、エンティティ、値オブジェクト、および集約ルートの間の依存関係に従って集約を確立することです。
- 3 番目のステップは、ビジネス境界や意味論的な境界などの要素に基づいて、境界付きコンテキストを定義することです。
ステップバイステップで詳しく説明しましょう。
ステップ 1: エンティティや値オブジェクトなどのドメイン オブジェクトを識別する
シナリオ分析に基づいて、これらのコマンドまたはドメイン イベントを開始または生成するエンティティと値オブジェクトを分析して見つけ出し、エンティティまたは値オブジェクトに関連するコマンドとイベントをエンティティに収集します。解析対象エンティティとコマンドの関係を以下の図に示します。分析を通じて、休暇フォーム、承認コメント、承認ルール、人事、組織関係、クレジット カードの詳細、勤怠の詳細、勤怠統計などのエンティティと値オブジェクトが見つかりました。
ステップ 2: 集計を定義する
集約を定義する前に、まず集約ルートを見つけます。上記のエンティティから、「休暇フォーム」と「人事」の 2 つの集約ルートが見つかります。次に、どのエンティティと値オブジェクトが集約ルートに密接に依存しているかを見つけます。承認意見、承認ルール、休暇届は密接な関係があり、組織関係は人事と密接な関係があることが分かりました。
これらのエンティティ間の関係を調べたところ、クレジット カードの詳細、勤怠の詳細、勤怠統計が存在することがわかりましたが、これらのエンティティには集約ルートがありません。ドメイン モデリングではこのような状況によく遭遇するため、この種のシナリオでは特別な方法で対処する必要があります。
クレジット カードの詳細、勤怠の詳細、および勤怠統計のエンティティは互いに独立しており、集約ルートは見つかりません。これらはリッチなドメイン モデルではありませんが、勤怠のビジネス ロジックを一緒に完成させ、高いビジネス結合性を持っています。これらの複数のビジネス関連エンティティを 1 つの出席集計にまとめます。マイクロサービスを設計するとき、私たちは今でも DDD の設計および分析手法を使用します。集約内のエンティティを管理するための集約ルートがないため、従来の方法を使用してエンティティを管理できます。
分析の結果、休暇、人事組織関係、勤怠の3つの集計を設定しました。このうち、休暇集計には休暇フォーム、承認意見エンティティ、承認ルールなどの値オブジェクトがあります。人事組織関係は、人事関係や組織関係などのエンティティを集約します。出席集計には、クレジット カードの詳細、出席の詳細、出席統計などのエンティティが含まれます。
ステップ 3: 境界付きコンテキストを定義する
人事と組織の関係の集約と休暇申請の集約は共同して休暇申請というビジネス機能を完了するため、この 2 つは休暇申請という限定されたコンテキスト内にあります。出席集計だけでも、出席統計の限定されたコンテキストを構成します。したがって、休暇と出勤の統計に関してビジネスを 2 つの限定されたコンテキストに分割し、休暇と出勤に関する 2 つのドメイン モデルを確立します。
4. マイクロサービスの分割
理論的には、境界付きコンテキストはマイクロサービスとして設計できますが、責任の単一性、機密性の高いサービスと安定したサービスの分離、非機能要件 (柔軟なスケーリング、バージョンのリリースなど) など、さまざまな外部要因を包括的に考慮する必要があります。頻度とセキュリティ要件）、ソフトウェア パッケージのサイズ、チームのコミュニケーション効率、技術的な異質性、その他のビジネス以外の要因。
このプロジェクトでは、主に単一責任の原則を考慮してマイクロサービスを分割します。したがって、制限されたコンテキストに従って、休暇と出席という 2 つのマイクロサービスに分割できます。このうち、休暇マイクロサービスには人事組織関係と休暇の 2 つの集約が含まれ、勤怠マイクロサービスには勤怠集計が含まれます。
この時点で戦略設計は終了です。戦略的な設計を通じて、ドメイン モデルを確立し、マイクロサービスの境界を分割しました。次のステップは戦術設計、つまりマイクロサービス設計です。Leave マイクロサービスを例として、その設計プロセスを説明しましょう。
戦術的なデザイン
戦術的設計は、ドメイン モデルに従ってマイクロサービスを設計するプロセスです。この段階では主に、マイクロサービス内のドメイン オブジェクトを整理し、ドメイン オブジェクト間の関係を整理し、コード モデルと階層化アーキテクチャ内でのそれらの位置を決定し、ドメイン モデルとマイクロサービス モデル間のマッピング関係、およびサービス間の依存関係を確立します。
戦術的設計フェーズで推奨される参加者: ドメイン専門家、プロダクト マネージャー、アーキテクト、プロジェクト マネージャー、開発マネージャー、テスト マネージャー。
戦術的な設計には、マイクロサービス ドメイン オブジェクトの分析とマイクロサービス コード構造の設計の 2 つのフェーズが含まれます。
1. マイクロサービス ドメイン オブジェクトを分析する
ドメイン モデルには多くのドメイン オブジェクトがありますが、これらのオブジェクトは比較的重いビジネス属性を持っています。ドメイン モデルからマイクロサービスへの移行を完了するには、さらなる分析と設計が必要です。イベント ストームに基づいて、ドメイン オブジェクトとその関係をさらに調整し、イベント ストームが見逃す可能性のあるビジネスおよび技術的な詳細を補足します。
マイクロサービスではどのサービスを分析する必要がありますか? サービスの階層化? アプリケーション サービスによって構成および調整されるサービスは何ですか? ドメイン サービスにはどのようなエンティティとエンティティ メソッドが含まれますか? どのエンティティが集約ルートですか? エンティティにはどのようなプロパティとメソッドがありますか? どのオブジェクトを値オブジェクトとして設計する必要があるかなど。
サービスの識別と設計
イベント ストームのコマンドは、外部操作やビジネス動作の一部であり、マイクロサービスによって提供される機能でもあります。マイクロサービスのアプリケーションサービスやドメインサービスに相当することが多いです。サービスの識別と設計の開始点としてコマンドを使用できます。具体的な手順は次のとおりです。
- コマンドに従ってアプリケーション サービスを設計し、アプリケーション サービスの機能、サービスの収集、構成、オーケストレーション方法を決定します。サービス コレクション内のサービスには、ドメイン サービスや他のマイクロサービスのアプリケーション サービスが含まれます。
- アプリケーション サービスの機能要件に従ってドメイン サービスを設計および定義します。ここで注意してください: アプリケーション サービスは、複数の集約されたドメイン サービスで構成されている場合があります。
- ドメイン サービスの機能に応じて、ドメイン サービス内のエンティティと機能を決定します。
- エンティティの基本的なプロパティとメソッドを設計します。
さらに、ドメイン イベントの非同期処理も考慮する必要があります。
サービスの特定と設計を説明するために、承認のために送信するというアクションを例に挙げます。
承認のために送信するための一般的なプロセスは次のとおりです。
- 休暇の種類と期間に応じて、休暇承認ルールをクエリして、次の承認者の役割を取得します。
- 承認ロールに応じて個人と組織の関係から次の承認者を問い合わせます。
- 承認者を休暇フォームに割り当て、承認ルールを休暇フォームに保存します。
- 分析を通じて、アプリケーション層とドメイン層で次のサービスとメソッドを設計する必要があります。
アプリケーション層:アプリケーション サービスを承認のために送信します。
ドメイン層:ドメイン サービスには、承認ルールのクエリ、休暇プロセス情報サービスの変更、および承認ルールに従った承認者サービスのクエリが含まれます。これらはそれぞれ、休暇と人事組織の関係の集合体に位置します。休暇フォームエンティティには休暇プロセス情報を変更するメソッドがあり、承認ルール値オブジェクトには承認ルールを問い合わせるメソッドがあります。人物エンティティは、承認ルールに従って承認者を問い合わせるメソッドを持ちます。以下の図は、分析したサービスとそれらの間の依存関係を示しています。
サービスの識別と設計のプロセスはこれで終わりです。集合体のオブジェクトを再度設計しましょう。
集合体のオブジェクト
脱退要求集約では、集約ルートは脱退要求です。休暇フォームを複数レベルでレビューすると、複数の承認意見が生成されますが、クエリの便宜上、承認意見をエンティティとして設計できます。休暇申請が承認されると休暇申請承認のドメインイベントが生成されるため、休暇申請イベントエンティティも存在します。休暇集計には、承認コメント (承認者、承認ステータス、承認コメントの記録) と休暇イベント エンティティのエンティティがあります。
休暇フォーム集計の値オブジェクトを分析してみましょう。休暇を申請する人と次の承認者のデータは、人事組織関係集約内の人事エンティティから取得され、値オブジェクトとして設計できます。従業員タイプ、休暇タイプ、および承認ステータスは列挙値タイプであり、値オブジェクトとして設計できます。休暇承認ルールを決定した後、その承認ルールを休暇フォームの値オブジェクトとして使用することもできます。休暇申請の集計には、休暇申請者、人事タイプ、休暇タイプ、次の承認者、承認ステータス、および承認ルールの値オブジェクトが含まれます。
要約すると、leave 集約オブジェクトの関係図を描くことができます。
人的組織関係の集約では、人員間の組織関係を確立し、組織関係タイプを通じて優れた承認リーダーを見つけることができます。その集約ルートは人材であり、エンティティは組織関係 (組織関係タイプおよび上位の承認リーダーを含む) を持ち、その中の組織関係タイプ (プロジェクト マネージャー、部門長、部長など) が値オブジェクトです。優れた承認リーダーは人材の集合ルートから生まれ、価値オブジェクトとして設計できます。人事と組織の関係の集約には、次の値オブジェクトが含まれます: 組織関係タイプ、上司の承認リーダー。
まとめると、人事組織関係集約オブジェクト関係図を再度描くことができます。
マイクロサービス内のオブジェクトマニフェスト
各ドメイン オブジェクトの属性を決定した後、コード モデル内の各ドメイン オブジェクトのコード オブジェクト (コード オブジェクトのパッケージ名、クラス名、メソッド名を含む) を設計し、1 対 1 のマッピング関係を確立できます。ドメインオブジェクトとコードオブジェクトの間。このマッピング関係に従って、関連担当者はビジネス ロジックが配置されているコードの場所をすぐに見つけることができます。上記の分析後、次の図に示すように、マイクロサービス内のオブジェクト リストを分析できます。
2. マイクロサービスのコード構造を設計する
DDD のコード モデルと各ドメインのオブジェクトのパッケージ、クラス、メソッドに従って、Leave マイクロサービスのコード構造を定義し、コード オブジェクトを設計できます。
アプリケーション層のコード構造
アプリケーション層には、アプリケーション サービス、DTO、およびイベント発行に関連するコードが含まれます。LeaveApplicationService クラスで集計に関連するアプリケーション サービスを実装し、外部マイクロサービスの認証とアクセス許可のためのアプリケーション サービスを LoginApplicationService でカプセル化します。
ここで注意してください: アプリケーション サービスのロジックが複雑な場合、アプリケーション サービスはクラスを構築できます。これにより、クラスのコードが大きくなりすぎてメンテナンスが困難になることを回避できます。
ドメイン層のコード構造
ドメイン層には、1 つ以上の集約エンティティ クラス、イベント エンティティ クラス、ドメイン サービス、ファクトリ、およびウェアハウス関連のコードが含まれます。集約は集約コード ディレクトリに対応し、集約はコード内で完全に分離され、集約はアプリケーション層を通じて調整されます。
Leave マイクロサービス ドメイン レイヤーには、Leave と人事の 2 つの集合が含まれています。スタッフ コードと休暇コードは、それぞれの集合体のディレクトリ構造内のコード パッケージに配置されます。ビジネスの発展に伴い、人事関連の機能を休暇マイクロサービスから分離する必要がある場合は、人事集計コード パッケージを少し変更して独立してデプロイし、人事マイクロサービスとしてすぐにリリースするだけで済みます。この時点で、マイクロサービスのドメイン オブジェクト、レイヤー、依存関係が明確に分類されます。マイクロサービスの全体的なアーキテクチャとコードモデルは基本的に完成しています。
フォローアップ作業
1. 詳細設計
ドメインモデルとマイクロサービスの設計が完了したら、マイクロサービスも詳細に設計する必要があります。主に、エンティティの属性、データベースのテーブルとフィールド、エンティティとデータベースのテーブル間のマッピング、サービスパラメータの仕様と機能の実現などの内容が設計されます。
2. コードの開発とテスト
開発者は、詳細な設計文書と機能要件に従って、ビジネス機能に対応するコードの場所を見つけて、コードの開発を完了するだけで済みます。コード開発が完了したら、開発者は単体テスト ケースを作成し、バッフル シミュレーション依存オブジェクトに基づいてサービス テストを完了する必要があります。
要約する
今日は、オンライン休暇と出勤プロジェクトを通じて DDD 設計プロセスを実行しました。
DDD の戦略的設計はイベント ストームから始まり、エンティティなどのドメイン オブジェクトを見つけ、集約を構築するための集約ルートを見つけ、境界のあるコンテキストを分割し、ドメイン モデルを構築する必要があります。
戦術的な設計は、イベント ストームのコマンドから始まり、サービスを特定して設計し、各層でのサービスの依存関係を確立し、マイクロサービス内のエンティティと値オブジェクトを設計し、マイクロサービス内のすべてのドメイン オブジェクトを見つけて、ドメイン オブジェクトとコードの間の関係を確立します。オブジェクト、マッピング関係。
このようにして、プロジェクト チームはマイクロサービスの開発とテストにおいて適切な指導を受けることができます。