DAOとRepositoryの違いを徹底解説！初心者にもわかるポイント整理

---

DAOとRepositoryの違いをわかりやすく解説する

DAOはData Access Objectの略で、データベースや他のデータストアとやり取りする窓口を作る設計パターンです。つまり、実際のSQLを発行したり、データの変換を担当する役割を担います。対してRepositoryは別の考え方で、ドメイン（私たちが表現したい現実世界の概念）を扱う集合のような振る舞いを提供します。Repositoryは「この型のオブジェクトを集めて、取得・追加・削除する」といった操作を、ドメインの文脈で扱えるようにします。実際のコードでは、Repositoryは内部でDAOを使ってデータを取り出すことが多いですが、外部に対しては直接データベース操作を公開しません。つまり、DAOはデータのアクセス方法そのものを扱い、Repositoryはドメインの観点でデータを扱う方法を提供すると覚えると混乱を減らせます。ユースケースを考えると、例えば「ユーザー情報を扱う場合」、DAOは「データベースのテーブルと列を直接操作する窓口」です。これに対してRepositoryは「ユーザー」というドメインの概念を扱い、ビジネス上の検索条件や集約を意識した操作を提供します。これらの違いを知っておくと、あとでコードを読むときにも役立ちます。
実務での設計のコツとしては、責務を分けること。DAOはデータそのものの取得・保存・変換を担当し、Repositoryはドメインの振る舞いを表現する集合の入口となるよう心掛けるのが基本です。

• DAOはデータストアと直接やり取りする窓口で、SQLの実行やデータの変換、接続の管理などを担当します。
• Repositoryはドメインの視点でデータを扱う集合のインタフェースで、ビジネスロジックに合わせた操作を提供します。
• DAOは低レベルのデータアクセス、Repositoryは高レベルの抽象で、両者は分担して設計するのが基本です。

実務での使い分けのコツと具体例

DDDの文脈で Repository はドメインの意思を表現するインタフェースとして用いられ、取得・保存の操作をビジネス用語で提供します。対して DAO はデータベースへ直接アクセスする低レベルの実装です。設計上のポイントは、インタフェースの命名と境界の明確さにあります。たとえば、"UserRepository" という名前のインタフェースは「ユーザーというドメインを扱う集合の操作」を定義し、具体的なデータベース操作は裏側の DAO が受け持つようにします。実装では、DAO は SQL や ORM の露出部分を隠し、Repository は「FindById」「FindAll」「Add」など、ドメインの語彙で機能を定義します。こうすると、データベースを変更しても Repository の呼び出し方は変わらず、ビジネスロジックは安定します。さらに、テストの観点でも、Repository をモックすることでドメインの挙動を検証しやすくなり、DAO をモックする必要性は減ります。
この区分を実務に落とすときの実例として、テスト環境を整える際に「DAOはスタブ化してDB接続を模倣する」「Repositoryはモックしてビジネスロジックのみを検証する」という手順を採ると、エンジニアが増えても保守が楽になります。

able>用語役割DAOデータストアへ直接アクセスする窓口。SQLの実行やデータ変換を担う。Repositoryドメインの視点でデータを扱う集合のインタフェース。ビジネスロジックに合わせた操作を提供。

ピックアップ解説

友だちと雑談している雰囲気でいうと、DAOはコンピュータの“データベースへ直接行く窓口”みたいな存在。SQLの実行やデータの変換を実際に動かす役割だよ。一方、Repositoryはその上にある“本棚”のような役割で、私たちのドメイン（例えば『ユーザー』という概念）を扱うための集合的操作を提供する。DAOがデータの事実を扱うのに対して、Repositoryはビジネスの言葉でデータを扱えるようにする。設計を分けておくと、後でデータベースを別のものに変えるときにもRepositoryの呼び出し方は変わらず、ビジネスロジックは安定して動き続けるよ。

---