{"componentChunkName":"component---src-templates-post-template-js","path":"/posts/data-access-patterns","result":{"data":{"markdownRemark":{"id":"8797a892-00fc-5ac1-b45e-643b75610d07","html":"

はじめに

\n

アプリケーション・アーキテクチャについて議論する中で、最近は DDD の戦術的設計やクリーンアーキテクチャなどがキーワードとして解説されることが多いです。

\n

そんな中、データアクセスの実装については Repository 意外の情報源が少なく、また Repository についても「データアクセス用のクラス」くらいの曖昧な定義で使われているケースも多いと思います。

\n

この記事では、そんなデータアクセスのパターンについて改めて整理し、よく見かける議論の 1 つである「Rails の ActiveRecord や Laravel の Eloquant による Repository の実装」についても考察してみます。

\n

注意事項

\n

内容の正確性について

\n

この記事はドメイン駆動設計に関する各種書籍や PoEAA などを参考にしていますが、情報源によって同じ言葉が違う意味で使われていることがあります。

\n

できるだけよく使われている意味で整理しようとしていますが、筆者の主観が入っている部分もありますので、ご了承ください。

\n

用語について

\n

記事の中で

\n\n

という用語を使いますが、こちらは過去に書いた

\n\n

という記事内と同じ意味で使っています。

\n

また、上記の記事の「コアなルール」のことを「ドメインロジック」と表現させていただきます。

\n

表記について

\n

記事の中で書籍『エンタープライズアプリケーションアーキテクチャパターン』を参考にしている箇所では『PoEAA』と省略表記させていただきます。

\n

データアクセスのパターン整理

\n

それでは本題に入ります。

\n

この記事では、まず最初にデータアクセスについて以下の 3 つのパターンを整理してみます。

\n\n

細かく分類すればもっと多数のパターンに分けられますが、まずはこのくらいの分類が分かりやすいのではないかという考えです。

\n

また、これらと併用して QueryService というクラスを設けるケースもありますが、そちらの説明は今回は省略します。\nQueryService については以下の記事が非常に分かりやすいです。

\n\n

では、ここから上記の 3 パターンについて書いていきます。

\n

Table Data Gateway パターン

\n

Table Data Gateway パターンをざっくり言えば、DB のテーブルと 1 対 1 に対応するデータアクセス用のクラスを設けるというものです。

\n

Java 界隈には Data Access Object (DAO) と呼ばれるパターンがありますが、DAO は Table Data Gateway と同じものを指していると言われています。

\n

実装イメージ

\n

擬似言語による実装イメージは以下のようになります。

\n
TaskTableDataGateway {\n  find(id)\n  findWithName(name)\n  insert(name)\n  update(id, name)\n  delete(id)\n}
\n

※ メソッド名は『PoEAA』p153 を参考にしています。

\n

メリット

\n

DB のテーブルと 1 対 1 に対応するクラスを作成してデータを取り出すのは、非常にシンプルで理解が簡単です。

\n

デメリット

\n

呼び出し側がデータモデルを意識することになります。\n例えば Service から Table Data Gateway を呼び出す場合、ビジネスロジックがデータモデルに依存することになります。

\n

また、Service クラスが Table Data Gateway を呼び出すようなアーキテクチャの場合、1 つの Service クラスが必要とする Table Data Gateway の数がかなり多くなるケースがあります。

\n

さらに、Order と OrderDetail など、同時に DB からロードすべきデータを同時にロードすることを保証できず、ビジネスロジック層でオブジェクトの整合性がとれていない瞬間を生んでしまいます。

\n

なお、これら 3 つのデメリットは、Repository パターンを使うことで解消可能です。

\n

関連パターン

\n

類似のパターンとして、以下のような実装も考えられます。

\n
TaskTableDataGateway {\n  find(id)\n  findWithName(name)\n  insert(task)\n  update(task)\n  delete(task)\n}
\n

違いは insert、update、delete メソッドの引数がテーブルと対応するクラスのオブジェクトになっていることです。

\n

ActiveRecord パターン

\n

続いて、ActiveRecord パターンについてです。

\n

ActiveRecord という単語で Ruby on Rails の OR マッパー「ActiveRecord」を思い浮かべる方も多いと思いますが、それは ActiveRecord パターンを実装したものです。

\n

同様に、Laravel の Eloquant も ActiveRecord パターンを実装した OR マッパーです。

\n

ActiveRecord パターンでは、ドメインモデルを DB のテーブルと 1 対 1 対応させ、データアクセスのメソッドも持たせます。\n（ここで言うドメインモデルは、データとドメインロジックを持つクラスのことです）

\n

実装イメージ

\n

擬似言語による実装イメージは以下のようになります。

\n
Task {\n  id\n  name\n\n  isAssigned()\n\n  insert()\n  update()\n  delete()\n}
\n

※ メソッド名は『PoEAA』p170 を参考にしています。

\n

このように、

\n\n

を同じクラスが持つことになります。

\n

※ メソッド名は OR マッパーにより異なる場合があります

\n

メリット

\n

ActiveRecord パターン最大のメリットは、Rails の ActiveRecord や Laravel の Eloquant といった ActiveRecord 系の OR マッパーを使うことで、非常に低コストで実装できることです。

\n

また、これらのフレームワークは近年プログラミングの入門として選択されることも増えており、経験のあるエンジニアが多いです。

\n

デメリット

\n

ActiveRecord パターンでは、ドメインモデルと DB が 1 対 1 対応になるため、ビジネスロジックはデータモデルと強く結合します。

\n

また、1 つのクラスがドメインモデルとデータアクセスという複数の役割を持つことになってしまいます。

\n

Repository パターン

\n

最後に Repository パターンです。

\n

Repository パターンは、コレクションライクなインタフェースで、「集約」という単位でデータを読み書きするデータアクセスのパターンです。

\n

今まで紹介した 2 パターンと異なり、Repository は DB と 1 対 1 対応させるのではなく、ドメインモデルの都合でデータアクセスを取り扱います。

\n

実装イメージ

\n

擬似言語による実装イメージは以下のようになります。

\n
TaskRepository {\n  taskOfId(id)\n  taskOfName(name)\n  save(task)\n  remove(task)\n}
\n

※ メソッド名は『実戦ドメイン駆動設計』p405 を参考にしています。

\n

これだけ見ると Table Data Gateway パターンと同じように見えるかもしれませんが、

\n\n

といった違いがあります。

\n

この違いについては以下の記事が非常に分かりやすいです。

\n\n

メリット

\n

Repository を使うと、Repository を呼び出すビジネスロジック層が、データモデルに依存しなくなります。\nそのため、ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ・クリーンアーキテクチャなどで語られる、依存性逆転が可能になります。

\n

また、Table Data Gateway とは異なり、Service などのクラスに多数必要とされにくくなったり、ロードしたオブジェクトの整合性のない状態を防ぐことができます。

\n

デメリット

\n

Repository パターンのメリットや目的を理解するのは、他のパターンと比べて何段階か難易度が高いです。

\n

そのため、どんなパターンなのか理解しているエンジニアも少ないです。

\n

関連パターン

\n

上の例では最近 DDD などの文脈で見かけるリポジトリの実装イメージを示しましたが、『PoEAA』p345 では以下のようなインタフェースとして紹介されています。

\n
TaskRepository {\n  matching(criteria)\n}
\n

検索条件を表す criteria オブジェクトを引数として検索するというものです。

\n

どちらが正しいということはできませんが、重要なポイントは、どちらも「ドメインモデルを中心的に考えたインタフェースになっていること」だと思います。

\n

どのパターンを使うか

\n

ここまで、最近の開発でよく見かけるデータアクセスのパターンを整理してきました。

\n

この中のどのパターンを使うかですが、「上記のメリット・デメリットを踏まえて、今回の状況ではどうするかを考える」というのが私の意見です。

\n

例えば、「DDD だから Repository じゃないと絶対にダメ」といったことは必ずしもなく、トレードオフを理解した上で ActiveRecord パターンを採用してもいいと思います。

\n

それ以上に前提として理解しておくべきポイントとして、どのパターンを使うかは、

\n\n

の 2 箇所について検討する必要があります。

\n

ビジネスロジック層とのインタフェース

\n

データアクセスの処理は主に Service (または ApplicationService、UseCase。アーキテクチャによっては Controller) といったクラスから呼び出すことになりますが、呼び出し先として

\n\n

のどれを使うか、という議論がまずあります。

\n

これは各パターンのメリット・デメリットを踏まえて決めることになります。

\n

その内部実装についてが少しややこしいかもしれません。

\n

データアクセス層の内部実装

\n

ActiveRecord パターンを採用する場合は、ActiveRecord 系の OR マッパーを使うことが多いです。\nしかし、Table Data Gateway や Repository を使う場合は、その内部を自前で実装することが多いです。

\n

ここでは特に Repository の内部実装について書いていきます。

\n

Repository の内部実装の方法

\n

Repository の内部を実装する際は、何らかの OR マッパーを使うことが多いです。

\n

OR マッパーとしては、

\n\n

などがあります。

\n

また、Table Data Gateway を Repository の内部実装として使うといったこともできます。

\n

Repository と他のデータアクセスパターンの関係

\n

ここでポイントは、Repository の内部に Table Data Gateway や ActiveRecord が登場するケースがあることです。

\n

つまり、Table Data Gateway や ActiveRecord には、

\n\n

といった選択肢があるということになります。

\n

最後に、後者の「ビジネスロジック層とのインタフェースは Repository とし、内部実装を Table Data Gateway (または ActiveRecord) にする」パターンについて書いていきます。

\n

Rails の ActiveRecord や Laravel の Eloquant による Repository の実装について

\n

Rails の ActiveRecord や Laravel の Eloquant といった ActiveRecord 系の OR マッパーは広く使われています。\nそのため、「Rails や Laravel にクリーンアーキテクチャを適用する」といった目的で、Repository の内部実装として ActiveRecord や Eloquant が使われている例を見かけることがあります。

\n

これに対して、「Rails の ActiveRecord や Laravel の Eloquant を使うなら、基本的に Repository は設けないほうが良い」というのが今の私の考えです。

\n

理由は主に 2 つあります。

\n

理由 1

\n

ActiveRecord パターンはデータベースと密結合になる代わりに実装コストを下げるのがメリットであり、Repository パターンとは逆の特徴を持ちます。

\n

そのため、ActiveRecord と Repository を組み合わせると、ActiveRecord パターンのメリットは得られなくなります。

\n

Repository パターンを採用する前提で、Repository の内部実装にすぎないと割り切って ActiveRecord 系の OR マッパーを使うことはありえなくはないですが、あまりメリットは大きくないと思います。

\n

理由 2

\n

ActiveRecord 系の OR マッパーが付属するフレームワークとして有名な Rails や Laravel は、ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ・クリーンアーキテクチャといった、Repository パターンを活かせる設計と相性がよくないとも考えています。

\n

ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ・クリーンアーキテクチャといった設計は、クラス数が増える代わりに疎結合で変更に強くなるといった特徴があります。

\n

これは Rails や Laravel などのスタンダードな実装とは対局にあり、言語としても、静的型付けのものを採用した方が相性が良いと思います。

\n

落としどころ

\n

以上の理由から、「Rails の ActiveRecord や Laravel の Eloquant を使うなら、基本的に Repository は設けないほうが良い」と考えています。

\n

Rails や Laravel でアーキテクチャを改善するのであれば、

\n\n

といったところから着手するのが望ましいと思います。

\n

例えば以下の書籍や記事が非常に参考になります。

\n\n

この内容と関連して、自分も過去に以下のような関連記事を書いています。

\n\n

おわりに

\n

以上、データアクセスのパターンについて考えていたことをまとめました。

\n

他にも様々な実装方法があると思いますが、勉強中の方の理解のとっかかりになれば嬉しく思います。

\n

用語の定義など含め、ご指摘事項などあれば Twitter の DM などでいただけますと幸いです。

\n

参考書籍

\n\n

\"\"

\n

\"\"

\n

\"\"

\n

\"\"

\n

\"\"

\n

\"\"

\n

\"\"

\n

関連記事

\n

以下、自分が過去に書いた関連記事です。

\n","fields":{"slug":"/posts/data-access-patterns","tagSlugs":["/tag/architecture/"],"autoRecommendPosts":["what-is-service-class","ddd-books","application-architecture-books","mlops-books"]},"frontmatter":{"date":"2021-12-01T02:09:43.952Z","description":"アプリケーション・アーキテクチャについて議論する中で、最近は DDD の戦術的設計やクリーンアーキテクチャなどがキーワードとして解説されることが多いです。\nこの記事では、データアクセスのパターンについて改めて整理し、よく見かける議論の 1 つである「Rails の ActiveRecord や Laravel の Eloquant による Repository の実装」についても考察してみます。","tags":["architecture"],"title":"データアクセスのパターンと、ActiveRecord や Eloquant による Repository の実装について","socialImage":null,"recommendPosts":null}}},"pageContext":{"slug":"/posts/data-access-patterns"}},"staticQueryHashes":["251939775","3942705351","401334301"]}