DDD の学習を改善するために行った既存の C# WinForm ベースのシステムに基づいてドメインをモデル化しようとしているので、問題を単純化するために架空の概念モデルをまとめました。システム自体には、システムのあらゆる面で使用される Entity Framework オブジェクトに多数のロジックが混在する典型的なビジネス ドメインはありませんでした。Big Ball Of Mud (BBOM) だった気がします。
仕事でいくつかの DDD の概念に取り組みましたが、全体的な理解を深めたいと思っています。Evans の Blue Book「Domain-driven Design: Tackling Complexity in the Heart of Software」と Scott Millets の「Patterns, Principles and Practices of Domain-Driven Design」を読みました。このテーマに関する無数のビデオを見るだけでなく、Vaughn Vernon の記事も参照してください。何年にもわたってより多くのデータ駆動型開発を行ってきたので、これが浸透するのに時間がかかっていると感じています.
したがって、仮想システムは、私が行ったシステムに大まかに従う、製品を構築するための厳密な品質管理システムです。
概念モデルは次のとおりです。
これには 3 つの部分があります。必ずしも境界付けられたコンテキストではありませんが、これらの境界付けられたコンテキストがどこにあるかを特定するのに苦労しています。
ビジネス プロセスには 3 つの部分があります。
- 製品の定義
このために、「ユーザー」は名前を含むさまざまな製品情報を入力します。この一環として、製品の厚さと素材を定義します。また、ビルダーが製品を構築するために使用する必要があるプロセスも定義します。また、目視検査と品質検査が必要かどうかも定義します。
- ビルド製品
プロセスの一環として、「ビルダー」が製品を組み立てます。ただし、これはビルダーの資格に関してのみ制限されます。Builder は、厚さの範囲と材料に基づくプロセスに対して認定されているため、ビジネス ルールでは、プロセスの厚さの範囲と材料の間にある製品の厚さについて認定されている場合にのみ Builder を選択できます。
- 検査
製品が構築されたら、検査することができます。この一環として、目視または品質検査のタイプが必要かどうかに応じて、最新の資格のある「検査員」が製品を検査できます。彼らは検査に合格するか不合格になります。
これらのプロセスの流れの一環として、製品のステータスが更新されます。これは次のようになります：
- 未組立
- 組み立てた
- 一部検査済み（2回の検査のうち1回検査済み）
- 合格した検査 (すべての検査が完了した)
- 失敗した検査 (すべての検査が失敗した)
以下は、考慮すべきドメイン外のシステムに関する情報です。
- システムは、検査を同時に入力できるマルチユーザーになるように設計されています
- 製品にデータが誤って入力された可能性があり、これを修正すると、入力されたビルドおよび検査データが無効になる可能性があります
- 入力されたデータは、さまざまなレポートで使用されます。
だから私はいくつかのアイデアが必要です：
- 境界付きコンテキストが存在する場所。
集約ルートをモデル化する方法 - どのデータをルートにする必要があり、どのエンティティ/値オブジェクトを含めるべきか。
境界のあるコンテキスト内に必要なドメイン オブジェクトのデータのみを含めますか。つまり、ドメイン オブジェクトを完全にハイドレートしませんか。
プロセスのさまざまな部分でステータスを計算するために何かを実装する方法。
- ドメイン データを正しく維持するために、データが誤って入力される可能性を処理する方法。
私はリポジトリの実装には興味がありません。純粋なドメインの概念だけに興味があります。
製品ステータスに関するデータの一貫性を保つために、複数のユーザーがデータを入力することに懸念があります。