コンテキスト: だから、とてつもなく複雑なドメイン モデルを構築しようとしています。ユーザーと話すと、システムの使用方法は複数あります（たとえば、従業員の観点からの方法と、雇用主の観点からの方法など）。実際には、コア ドメインを再利用する複数のアプリケーションです。
質問: 複数の観点からドメインを作成するのは間違っていますか? たとえば、ビジネスの運営に合わせてドメインを構築するということは、エンティティなどに関する追加情報を保持するあらゆる種類の関係クラスを作成することを意味します。リレーションシップ クラスは、親エンティティにロールバックできます。
アイデア？反論？私は完全に基地外ですか？
いいえ、これは絶対に適切です。Evan は、これらの「パースペクティブ」を彼の著書で Bounded Contexts と呼んでいます。
非常に複雑なドメイン モデルを使用する代わりに、特定の方法でドメインに適切に対処する単純なドメイン モデルを構築してみてください。境界付けられたコンテキストを相互にリンクして、より小さく単純な直接ドメイン モデルの Web を形成できます。
「コアドメイン」を事前に定義しようとするべきではないと思います。開発プロセスでそれを明らかにしましょう。さらに、2 つ (またはそれ以上) のパースペクティブに共通しないものは、「コア」に含めるべきではありません。
たとえば、従業員の観点からシステムの一部を構築します。これにより、「プロジェクト」、「タスク」、「顧客」などのエンティティを作成するように求められる場合があります。次に、従業員の観点から部分を構築します。これにより、新しいエンティティを構築し、「プロジェクト」と「タスク」を再利用するように求められる場合があります。そのとき、「プロジェクト」と「タスク」を、システムの残りの部分で共有される「コア ライブラリ」に移動します。
共通のエンティティが見つかることがありますが、異なる方法で関連しています。その場合、関係はエンティティ自体に組み込まれるのではなく、コンテキストによって注入される必要があります。