私は数年前から DDD を使用していますが、集約の設計に関してはまだ挑戦的です。それが DDD の楽しい部分であり、頭が回転します。私はプロジェクトのアーキテクトであり、モデルを設計している最中なので、この質問をしています。モデルがGUIと並行して進化し、顧客と一緒に要件を収集するときの反復です。今問題に。私たちのシナリオは、非常に大きな AR に成長しているいくつかの集合体に直面しているということです。私は、値オブジェクトを見つけて貧血ドメイン モデル トラップを回避するのが得意だと思います。しかし、私はこのような状況になったことはありません。一例として、私たちのシステムは携帯電話のアンテナを表す必要があります。アンテナは緑の野原にあります。しかし、アンテナは装備を備えたシェルターを持つことができます。アンテナはマイクロ波リンクを持つことができます。地面にファイバーラインを設置したり、無線要素を設置したり、電源を設置したりできます。それに直面。アンテナが終了した場合...これらの依存関係もすべて削除されます。それらはインストールの一部であるため（グリーンフィールドを除く:)）しかし、あなたは写真を手に入れます. アンテナ モデルは複雑です...そして大規模な AR は、同時実行ロック、パフォーマンス、メモリ消費に関して柔軟性がありません。
効果的な AR 設計に関する Vaughn Vernons の非常に優れた論文http://dddcommunity.org/library/vernon_2011/を読んだ後、大きな AR をバラバラに切り刻む必要があることに気付きました。
私のアイデアは、たとえば MicrowaveLinks を別の AR に移行するように Vernon が提案するようにすることです (実際にはそうではありませんが)。MicrowaveLink エンティティ (現在は AR) は、ID による参照アンテナです。MicrowaveLink Entity クラスには、AntennaId という値オブジェクト プロパティがあります。私たちのユースケースは、このシナリオをサポートしています。アンテナとリンクを一緒にリストすることはめったにありません。そのため、MicrowaveLinkRepository.ListByAntenna(Guid AntennaId) を介して MicrowaveLinks を読み込むことができます。
1) 以前にこの AR 分割を行ったことがありますか?どのようにしましたか? 2) この AR --> AR 関係を、ドメインの制約と DB (ORM として EF 5 を使用) の両方を通じてそのままサポートできましたか?
私の最適な目標は、アンテナのアンテナ.マイクロ波コレクションをスキップできるようにすることです。したがって、アンテナはリンクかどうかを認識していません。リンクは、どのアンテナに取り付けられているかを認識しています。また、MicrowaveLink エンティティでは、AntennaId プロパティのみが必要であり、できれば、アンテナが存在することを確認する DB 制約が必要です。
T-SQLスクリプトを使用して、EFまたはDBのシードメソッドにFK制約を手動で追加できることを認識しています。しかし、この関係は EF5 Code First Fluent マッピングによって何らかの形でサポートされるのでしょうか?