- UserRepository [オブジェクトを管理するための中央ファクトリ]
DDD リポジトリではFactoryではありません。リポジトリは、ドメイン オブジェクトの寿命の途中と最後を担当します。工場は最初に責任があります。概念的には、永続化と復元は、ドメイン オブジェクトの寿命の途中で発生します。
- UserMapper + UserDbTable [アプリケーション機能をマップし、CRUD 実装を提供するマッパー]
これらのクラスはドメイン層に属していません。これはデータ アクセスです。それらはすべてリポジトリの実装によってカプセル化されます (または、ORM を使用する場合はまったく存在しません)。
私の最初の質問は、モデルが永続レイヤーと通信する必要がある場合、リポジトリまたはマッパーに接続する必要があるかということです。個人的には、マッパーに連絡して必要な機能を提供するリポジトリに問い合わせるべきだと考えています。
モデルは永続層と通信する必要はありません。実際、モデルを可能な限り持続性にとらわれないようにする必要があります。ドメイン モデルの観点からは、リポジトリは単なるインターフェイスです。このインターフェイスの実装は、データ アクセスという別のレイヤーに属します。実装は後で、アプリケーション層のどこかに挿入されます。アプリケーション層は永続性とトランザクションを認識しています。ここでUnit Of Workパターンを実装できます(これもドメイン層には属しません)。
2 番目の懸念は、同じクラスのすべてのオブジェクトに対して 1 つのリポジトリのみが存在する必要があることです。つまり、シングルトンを作成することになります。しかし、アプリケーションに多数のドメイン モデル (20 としましょう) がある場合、20 個のシングルトンがあります。
まず、特定のドメイン オブジェクトに対して複数のリポジトリを作成できます。これは、Repository インターフェイスでの「メソッドの爆発」を回避したいため、ほとんどの場合に発生します。第二に、シングルトン リポジトリは悪い考えです。なぜなら、すべてのコンシューマを単一の実装に結合するため、特にユニット テストが難しくなるからです。第三に、20 以上のリポジトリを持っていても問題はありません。実際、より焦点を絞ったクラスがあればあるほど良いです。 SRPを参照してください。
アップデート：
通常の Factory パターンと DDD Factory を混同していると思います。DDD の用語では、オブジェクトがデータベースから復元されると、概念的には既に存在します (メモリ内の新しいオブジェクトであっても)。したがって、それを永続化して復元するのはリポジトリの責任です。DDD ファクトリは、複雑なドメイン オブジェクトがその寿命を開始するときに作用します。