DDD内のエンティティ間の関係

Question

私はDDDの初心者で、デザインのすべての原則に頭を下げるために、小さくてシンプルなドメインを扱っています。

私はこの単純なドメインを持っています：施設（Institution）と利用可能なWiFiスポット（Place）はデータベースに保存されています。施設なしでは存在する場所はありません。機関には管理者のユーザー譲受人（User）があり、新しい場所の追加、既存の場所の再割り当てまたは削除ができます。

Code can be found here。値オブジェクトの検証は、今のところ残っています。

これはMathias Verraes on child entitiesの影響を受けます。

正しいDDDデザインですか？少なくともそれに近い？

データ中心のプログラマですが、私は、親指のルールが集約ルートを介してアクセスしている場合、すべての施設のすべての場所をどのようにリストするのですか？

Uuidをエンティティ自体（Place::create）内に生成するという考えは良いですか？

譲受人（User）だけが場所を追加/削除できるというアイデアは、ドメイン自体で表現されるべきですか、それともクライアントの責任であるべきですか？この場合、譲受人が管理機関について知っているのが賢明です（institutionId：User？）。

Institution::placeByIdはDDDの原則を破っていませんか？たぶんそれはリポジトリの責任ですか？

Answer 1

集約ルートルールは書き込み側にのみ適用されます。この問題は、専用の読み取りモデルを持っていれば消えてしまいます。あなたは、あなたのユーザーのシナリオに合ったモデルを読みたいと思っているのです。

それ以外の場合は、施設からハッシュにすべての場所を追加して、そのフラットなリストを返すことができます。

集約ルートを集中化すると、更新シナリオについて考えるとき。機関とは無関係に更新することはできますか？そうであれば。それはそれ自身の集約ルートかもしれません。

通常、リポジトリは次のIDを決定する必要があります。

権限のリストを含むロールを使用して、すべてのメソッドを送信者に渡し、メソッド内のアクセスをチェックします。これにより、アクセス権の簡単なテストも可能になります。