domain-driven-design - すべての「バルク」操作はDDDのどこに属しますか？

Question

DDDの重要な概念の1つはリポジトリです。これにより、エンティティ（または集約ルート）を取得し、更新後に保存して戻すことができます。

エンティティを使用して「バルク」操作を実行する必要があり、エンティティの数によってそれらをメモリに取得することが絶対に不可能であると仮定します。つまり、操作はデータベースでのみ実行できます。

そのような「バルク」操作の場所はどこにありますか？それはリポジトリ上のメソッドである必要がありますか？データベース固有の操作でリポジトリの抽象化を「リーク」しませんか？事業運営をエンティティからリポジトリに移しませんか？

score 7 · Accepted Answer

サービスだと思います。

Evansは彼の本の中で、クラスに「悪臭がする」メソッドが属していないと思われるためにクラス内に入れるかどうか疑問がある場合は、その操作を使用してServiceFooクラスを作成することを推奨しています。

score 4 · Accepted Answer

void DoLongInvolvedTask();

一括タスクをメソッドとしてリポジトリに配置することに問題はないと思います。彼らは何も漏らしません。バルク操作を行うことは、データベース固有の操作を意味するものではありません。つまり、メソッドが ReBuildMSSQLIndexesOnMyBigTable() のようなものでない限りです。

score 3 · Accepted Answer

必要なものは、ドメイン駆動設計のサービスと呼ばれます。サービスは、手続き型タスクをモデル化するために使用されます。あなたが説明したような一括更新操作は、サービスの理想的な候補です。

編集:元のリンクが消えました。ここで DDD 用語集を見つけることができますが、元のページほど役に立ちません。http://dddcommunity.org/resources/ddd_terms/

score 1 · Accepted Answer

ドメインオブジェクトに保存、取得ロジックを持たないでください（ドメインモデルを使用していると仮定しています）。それがレポジトリの責任です。したがって、一括メソッドはリポジトリに属します。

ORM を使用している場合、リポジトリはデータベースに依存しません。彼らは、すべてのリクエストを ORM レイヤーに転送します。

独自のマッパーを作成している場合、リポジトリはリクエストをエンティティのマッパーに転送します。そして、このカップリングは大丈夫だと思います。

4 に答える 4