_customRoleRepositoryを次の例で実装するための推奨方法はありますか？ 以下のコードは、アプリケーションサービスで実行されます。DDDリポジトリの入力パラメータ
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetById(user.CustomRoleId);
または
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetForUser(user);
2つのオプションを指定すると、おそらく最初のIDにアクセスするとIDでアクセスする一貫性が保たれます。
可能であれば、特に、これが一般的な操作である場合は、データベースへの別のラウンドトリップを回避するためにユーザーを読み込むときに、カスタムロールを読み込むことをお勧めします。これは、読み取りモデルとして実装することができます。
これは、あなたが正しくあなたの凝集体をモデル化している... :)
CQRSのようなもの？ – Robert
用語はあなたが話す人に依存することができます:)しかし、私はしばしば、応答で必要とされる読み取りモデルにあらかじめ投影されている読み取りのための別個のデータストアがある場合に、CQRS（コマンドクエリ責任分離）という用語を使用します。イベントストリームに基づいて非同期に更新されます。しかし、CQS（Command Query Separation）は、書き込みモデル永続ストアに対して標準クエリを実行する一連のクエリを持つ場合にも有効です。クエリはアプリケーションでは_分離されていますが、読み取りモデルは完全には分離されていません。 –
私にとっては、単純にUsersテーブルをCustomRolesテーブルに追加し、読み込みモデルdtoを返した読み込みモデルクエリを実装すると、CQSになります。しかし、データがUIやAPIの応答データにまっすぐに向かうのは良い考えだと思います。ドメイン集約/エンティティと対話するために返されるデータを使用する場合は、ドメインモデルでドメインモデルを使用し、アクセス戦略を独立させているため、リポジトリで何をやっているかが優れています。 –
それを言うために憎しみが、DDD環境では、私の答えはどちらだろう。
最初の例では、役割リポジトリはユーザードメインを知らない可能性がありますが、アプリケーションからIDを取得して別のリポジトリに問い合せる必要があることをアプリケーションが知る必要があることを意味します。つまり、アプリケーションはユーザーと役割の間のマッパーとして機能しています。
第2の例では、役割リポジトリはユーザドメインについて知る必要があります。しかし、アプリケーションはもうroleIdについて知る必要はありません。だからそれは良いです。従来の2つのアプローチの間のトレードオフ。
しかしどちらの場合でも、アプリケーションでは情報を取得するために2つのリポジトリが必要です。より多くの関係が必要な場合はどうなりますか？リポジトリの数は急速に増加し、物事は混乱することがあります。
ドメインドリブンデザインでは、集約ルーツ（AR）とドメインコンテキストの観点から考える必要があります。あなたの文脈の例では、ユーザはARであり、その役割は子供になります。
実装の詳細のほとんどがアプリケーションから隠され、ドメインエンティティが実際にやるべきことに集中することができます。
CustomRoleはBC内の別のAggregateRootを表します。それはエンティティ（パーミッション）などを持っています複数のユーザーが同じCustomRoleを共有できます。あなたが提案するのは、CustomRoleを値オブジェクトとして扱うことです.CustomRoleが更新されると、その変更をそのロール内のすべてのユーザーに伝播する必要がありますか？ – Robert
同じbc内の2つのarは問題のように聞こえる。あなたの例では、役割を価値オブジェクトと見なします。私は役割を更新するために異なるBCを持っています。そして、ユーザーに役割が変更されたことを通知する通知を送信します。もちろん、これの多くは、実際に対処する複雑なビジネスロジックを持っているかどうかによって異なります。大きな画像を知らなくても、特定の推奨事項を作るのは難しいです。 – Cerad
ところで、これらの質問はhttp://programmers.stackexchange.com/ – Cerad
両方を想定しているが、あなたのニーズに応じて、同様に有効です。 GetForUserは、呼び出し元コードに有効なUser集約があることを確認してから、ロールを取得する前に有効です。呼び出し元コードに有効な値を設定する必要がある場合は、customRoleRepositoryをUser集計の知識に結合しますユーザー集約、そのカップリングは目的を持っています。
GetByUserIdはGetByIdと、より一貫性があり、少ないカップリングを持っているので、あなたのコンテキストでは、クライアントが有効なユーザーの集計を持っていない場合でも、GetByUserIdを呼び出すために重要ではありませんならば、それはあまりにも大丈夫です。あなたがByIdをロードする場合、私はまた、型付きアイデンティティvalueobjectsは、型の安全性の余分なレベルを提供する上で非常に参考にすることができ使用して見つけた
- 長所と短所についてのいくつかの会話ここhttps://stackoverflow.com/a/5377460/6720449、ここhttps://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg
何ですかユーザーとその役割がロードされていますか？ – tomliversidge
@tomliversidge authトークンを作成して、そのトークンと結びつけるためのロール権限を取得する – Robert