【りぽじとりぱたーん】

リポジトリパターンとは？

最終更新: 2026年10月1日

💡 業務の言葉で、データを出し入れする窓口

ドメインオブジェクトをコレクションのように扱う窓口を設け、データの取得・保存の詳細を分離する設計パターン。単にDB操作を別クラスへ移すことに限らず、業務の語彙で扱える境界を作ります。

📌 このページのポイント

上の矢印は業務から窓口を呼ぶ方向、下の線は実装の選択肢で同時保存ではありません。業務の対象を扱う境界であり、Gitのリポジトリとは区別します。

ひよこ

リポジトリは何をする？

ペンギン先生

ドメインオブジェクトの集合に対して、探す・追加する・保存するような窓口を提供するんだ。たとえば注文を扱う業務側はOrderRepositoryを通して取得し、SQLやDBの接続方法などの詳細は実装側へ任せる。Gitのリポジトリとは別の設計の話だよ。

ひよこ

DB操作を別クラスにすれば同じ？

ペンギン先生

それだけとは限らないよ。Fowlerの説明ではドメイン層とデータのマッピング層を仲介し、コレクションのような窓口を作ることが中心だね。単なるテーブル操作の寄せ集めより、業務で扱う対象と問い合わせの意味が見える設計を考えるんだ。

ひよこ

テストでDBを使わなくてよい？

ペンギン先生

業務側がインターフェースへ依存する設計なら、メモリ上のテスト用実装などへ差し替えて業務ロジックを確認できる。ただし、SQL・制約・トランザクション・実DBでの振る舞いまで確認したことにはならない。実DBとの結合テストも分けて行うよ。

ひよこ

テーブルごとに1つ作る？

ペンギン先生

DDDで更新と整合性を扱うなら集約ルートを単位に考える。注文とその明細を1つの集約として扱う場合、テーブルが複数でも窓口を無条件に分けないんだ。読み取り専用の問い合わせはCQRSなどで別経路にする設計もあるよ。

ひよこ

ORMの上にも必ず必要？

ペンギン先生

必須ではないよ。MicrosoftはEFのDbContextにもRepositoryとUnit of Workの役割があると説明している。業務の境界、問い合わせの重複、テストの分離に役立つかを見て判断しよう。インターフェースを付けるだけで、どんなDBにも変更なしで移行できるわけではないんだ。

もっと詳しく知りたい人へ

配列で動く実装はすべてモック？

テストの代役全体はテストダブルと呼べます。実際に簡略化した動作を行うものはフェイク、呼び出しや期待した振る舞いを検証するものはモック、と区別することがあります。目的を明記し、代役で実DBの差異まで確認できるとは考えないでください。

まとめ：ざっくりこれだけ覚えればOK！

「リポジトリパターン」って出てきたら「ドメインオブジェクトを扱う窓口とデータアクセスの詳細を分離する設計」と思えばだいたいOK！

📖 おまけ：英語の意味

「Repository Pattern」＝保管庫を表すrepositoryに由来する設計パターンの名称

💬 オブジェクトの集合へアクセスする窓口を表します。ソースコードを保管するGitリポジトリと、このデータアクセスの設計を区別してください。