Zenn
Open25

PoEAA

katzumikatzumi

What's PoEAA

PoEAA( Patterns of Enterprise Application Architecture )

エンタープライズ・アプリケーション開発者が直面する厳しい課題に直接応えるために書かれた。
著者が同じ設計アイデアが共通の問題に適用できると気づき、専門家の協力で40種類のパターンを抽出してまとめたもの。

katzumikatzumi

本家のパターンカタログ
https://www.martinfowler.com/eaaCatalog/index.html

いくつかのパターンはグルーピング化されるのでその目次には良さそう

  • Domain Logic Patterns
    • Transaction Script
    • Domain Model
    • Table Module
    • Service Layer
  • Data Source Architectural Patterns
    • Table Data Gateway
    • Row Data Gateway
    • Active Record
    • Data Mapper
  • Object-Relational Behavioral Patterns
    • Unit of Work
    • Identity Map
    • Lazy Load
  • Object-Relational Structural Patterns
    • dentity Field
    • Foreign Key Mapping
    • Association Table Mapping
    • Dependent Mapping
    • Embedded Value
    • Serialized LOB
    • Single Table Inheritance
    • Class Table Inheritance
    • Concrete Table Inheritance
    • Inheritance Mappers
  • Object-Relational Metadata Mapping Patterns
    • Metadata Mapping
    • Query Object
    • Repository
  • Web Presentation Patterns
    • Model View Controller
    • Page Controller
    • Front Controller
    • Template View
    • Transform View
    • Two-Step View
    • Application Controller
  • Distribution Patterns
    • Remote Facade
    • Data Transfer Object
  • Offline Concurrency Patterns
    • Optimistic Offline Lock
    • Pessimistic Offline Lock
    • Coarse Grained Lock
    • Implicit Lock
  • Session State Patterns
    • Client Session State
    • Server Session State
    • Database Session State
  • Base Patterns
    • Gateway
    • Mapper
    • Layer Supertype
    • Separated Interface
    • Registry
    • Value Object
    • Money
    • Special Case
    • Plugin
    • Service Stub
    • Record Set
katzumikatzumi

Domain Logic Patternsは、ビジネスロジックの一部であるドメインロジックを実装するためのパターンをまとめたもの
ドメインロジックとは、ドメインの問題に関連するロジックのことで、例えば金利計算や在庫管理などがある

Domain Logic Patternsには、以下の4種類がある

  • Transaction Script
    一連の処理を一つの手続きにまとめるパターン
  • Domain Model
    ドメインオブジェクトを作り、そのオブジェクトにロジックを持たせるパターン
  • Table Module
    データベースのテーブルに対応するモジュールにロジックを集約するパターン
  • Service Layer
    ドメインロジックを提供するサービス層を作るパターン
katzumikatzumi

Data Source Architectural Patternsは、データベースとのやり取りをするためのパターンをまとめたもの

Data Source Architectural Patternsには、以下の4種類がある

  • Table Data Gateway
    データベースのテーブルに対する操作を提供するオブジェクトのパターン
  • Row Data Gateway
    データベースの行に対応するオブジェクトのパターン
  • Active Record
    データベースの行に対応するオブジェクトで、自分自身を保存や削除できるパターン
  • Data Mapper
    データベースの行とドメインオブジェクトの間のマッピングを担当するオブジェクトのパターン
katzumikatzumi

Object-Relational Behavioral Patternsは、オブジェクトとリレーショナルデータベースの間の振る舞いの問題を解決するためのパターンをまとめたもの

Object-Relational Behavioral Patternsには、以下の3種類がある

  • Unit of Work
    ビジネストランザクションに影響されるオブジェクトのリストを管理し、変更の書き込みや同時実行性の問題の解決を調整するパターン
  • Identity Map
    データベースから読み込んだオブジェクトを一意に識別するためのパターン
  • Lazy Load
    オブジェクトが必要になるまでデータベースから読み込まないようにするパターン
katzumikatzumi

Object-Relational Structural Patternsは、オブジェクトとリレーショナルデータベースの間の構造の問題を解決するためのパターンをまとめたもの

Object-Relational Structural Patternsには、以下の8種類がある

  • Identity Field
    データベースのIDフィールドをオブジェクトに保存して、メモリ内のオブジェクトとデータベースの行の間の同一性を維持するパターン
  • Foreign Key Mapping
    データベースの外部キーをオブジェクトの参照にマッピングするパターン
  • Association Table Mapping
    データベースの関連テーブルをオブジェクトのコレクションにマッピングするパターン
  • Dependent Mapping
    データベースの依存オブジェクトを親オブジェクトにマッピングするパターン
  • Embedded Value
    データベースの単純な値オブジェクトを親オブジェクトに埋め込むパターン
  • Serialized LOB
    データベースの大きなバイナリや文字列オブジェクトをシリアライズして保存するパターン
  • Single Table Inheritance
    データベースの単一のテーブルに複数のサブクラスをマッピングするパターン
  • Class Table Inheritance
    データベースの複数のテーブルに複数のサブクラスをマッピングするパターン
katzumikatzumi

Object-Relational Metadata Mapping Patternsは、オブジェクトとリレーショナルデータベースの間のマッピングをメタデータで管理するためのパターンをまとめたもの

Object-Relational Metadata Mapping Patternsには、以下の3種類がある

  • Metadata Mapping
    オブジェクトとリレーショナルデータベースのマッピングの詳細をメタデータに保持するパターン
  • Query Object
    データベースのクエリを表すオブジェクトのパターン
  • Repository
    ドメインオブジェクトとデータソースオブジェクトの間に仲介するオブジェクトのパターン
katzumikatzumi

Web Presentation Patternsは、Webブラウザベースのユーザーインターフェースを実現するためのパターンをまとめたもの

Web Presentation Patternsには、以下の7種類がある

* Model View Controller
モデル、ビュー、コントローラーの3つのレイヤーに分けて、ユーザーインターフェースのロジックと表示を分離するパターン

  • Page Controller
    Webページごとにコントローラーを作成して、ユーザーのリクエストを処理するパターン
  • Front Controller
    Webページのコントローラーを一つに集約して、ユーザーのリクエストを処理するパターン
  • Template View
    HTMLテンプレートに動的なデータを埋め込んで、Webページを生成するパターン
  • Transform View
    XMLデータにXSLT変換を適用して、Webページを生成するパターン
  • Two-Step View
    ビューを2つのステップに分けて、最初に論理的な構造を生成し、次に具体的な表示形式に変換するパターン
  • Application Controller
    Webアプリケーションのナビゲーションロジックを一元管理するオブジェクトのパターン
katzumikatzumi

Distribution Patternsは、ネットワークを介したオブジェクトのやり取りを効率的にするためのパターンをまとめたもの

Distribution Patternsには、以下の2種類がある

  • Remote Facade
    細かい粒度のオブジェクトに対して、粗い粒度のファサードを提供して、ネットワーク越しの効率を向上させるパターン
  • Data Transfer Object
    ネットワーク越しにデータを転送するために、単純なデータ構造を使うパターン
katzumikatzumi

Offline Concurrency Patternsは、オフラインで行われるビジネストランザクションの間の競合を防ぐためのパターンをまとめたもの

Offline Concurrency Patternsには、以下の4種類がある

  • Optimistic Offline Lock
    競合を検出してトランザクションをロールバックすることで、競合を防ぐパターン
  • Pessimistic Offline Lock
    競合する可能性のあるデータにロックをかけて、競合を防ぐパターン
  • Coarse Grained Lock
    ロックの粒度を大きくして、競合の可能性とロックのコストをバランスさせるパターン
  • Implicit Lock
    ロックの存在を隠蔽して、競合を防ぐパターン
katzumikatzumi

Session State Patternsは、Webアプリケーションのセッションデータをどこに保存するかを決めるためのパターンをまとめたもの

Session State Patternsには、以下の3種類がある

  • Client Session State
    セッションデータをクライアント側に保存するパターン
  • Server Session State
    セッションデータをサーバー側に保存するパターン
  • Database Session State
    セッションデータをデータベースに保存するパターン
katzumikatzumi

Base Patternsは、エンタープライズアプリケーションの開発においてよく使われる基本的なパターンをまとめたもの

Base Patternsには、以下の11種類がある

  • Gateway
    データソースや外部システムとのやり取りを抽象化するパターン
  • Mapper
    データソースとオブジェクトのマッピングを行うパターン
  • Layer Supertype
    同じレイヤーに属するオブジェクトに共通の振る舞いや属性を提供するパターン
  • Separated Interface
    インターフェースと実装を分離するパターン
  • Registry
    オブジェクトの参照をグローバルに管理するパターン
  • Value Object
    不変で等価性を持つオブジェクトを表すパターン
  • Money
    金額や通貨を表すパターン
  • Special Case
    特殊な状況を表すオブジェクトを作るパターン
  • Plugin
    拡張性の高いアプリケーションを作るために、プラグインと呼ばれるコンポーネントを使うパターン
  • Service Stub
    テストや開発のために、外部サービスの代わりにスタブと呼ばれるオブジェクトを使うパターン
  • Record Set
    データベースから取得したレコードの集合を表すパターン
katzumikatzumi

Domain Logic Patterns毎のテストのしやすさ考察

  1. Domain Model
    ドメインオブジェクトは単体テストやモックテストがしやすい。
    安定度いValue Objectすることで、テストも壊れにくい
  2. Service Layer
    サービスはインターフェースを持つため、モックテストがしやすく、サービス間の依存関係も明確になる。また、サービスはドメインロジックの粒度を調整できるため、テストのしやすさが高い
  3. Transaction Script
    トランザクションスクリプトは手続き的な記述で、単体テストはしやすい。
    ただし再利用性や可読性が低く、複雑なドメインロジックに対応できない可能性がありテストのしやすさは一段下がる。
  4. Table Module
    テーブルモジュールはテーブルごとにドメインロジックを記述するため、データベースへの依存度が高くなる。また、テーブルモジュールはオブジェクト指向的ではないため、モックテストがしにくくなり、4つのパターンでは最もテストしにくい
katzumikatzumi

Domain Logic Patterns毎の向いているビジネスロジックについて考察

  • Transaction Script
    ビジネスロジックが単純で変更が少ない場合に適している。
    コードがシンプルで分かりやすいが、複雑なロジックや共通化が必要な場合には不向き
  • Domain Model
    ビジネスロジックが複雑で変更が多い場合に適している。
    コードが柔軟で再利用性が高いが、設計や実装には高いスキルや労力が必要となる
  • Table Module
    ビジネスロジックがデータベースに密接に関連している場合に適している
    コードがデータベースと一致して理解しやすい面があるものの、オブジェクト指向的な設計やテストには適していない
  • Service Layer
    ビジネスロジックが複数のアプリケーションやクライアントから利用される場合に適している
    コードが機能や役割によって分離されて保守性が高くなるが、サービス間の依存関係や境界を管理する必要がある
katzumikatzumi

Active Recordは、Data Source Architectural Patternsに分類されるパターンですが、他のパターンとも関連がある

Data Source Architectural Patterns以外のパターンで以下の様な関連がある

  • Domain Logic Patterns
    • Domain Model
      Active Recordは、ドメインモデルの意味表現に使われる要素として機能する
    • Row Data Gateway
      Active Recordは、データベースの行に対応したオブジェクトとして機能する
    • Table Module
      Active Recordは、データベースのテーブルに対応したモジュールでビジネスロジックを実装するパターンを有する
  • Object-Relational Behavioral Patterns
    • Unit of Work
      Active Recordは、オブジェクトの変更を追跡し、データベースに一括で反映するパターンを有する
    • Identity Map
      Active Recordは、同じデータベースのレコードに対応するオブジェクトを一意に管理するパターンを有する
  • Object-Relational Structural Patterns
    • Identity Field
      Active Recordは、オブジェクトに一意な識別子を持たせるパターンを有する
    • Foreign Key Mapping
      Active Recordは、オブジェクトの関連をデータベースの外部キーで表現するパターンを有する
  • Object-Relational Metadata Mapping Patterns
    • Metadata Mapping
      Active Recordは、オブジェクトとデータベースのマッピングは設定より規約（convention over configuration）で表現します
  • Web Presentation Patterns
    • Model View Controller
      Active Recordは、画面表示のロジックをモデル、ビュー、コントローラーに分離するパターンの中のモデルを担っています
  • Distribution Patterns
    • Remote Facade
      Active Recordは、複雑なデータモデルをシンプルに扱えるようにし、ネットワーク越しのデータアクセスのパフォーマンスを改善するために以下の様なメソッドが提供されています
      • includesメソッド
        関連するテーブルのデータを一括で取得してN+1問題を回避する
      • joinsメソッド
        テーブル同士を結合してデータを取得する
      • scopesメソッド
        よく使うクエリを名前付きで定義して再利用する
      • delegateメソッド
        関連するオブジェクトのメソッドを呼び出す際に中間オブジェクトを省略する
  • Offline Concurrency Patterns
    • Optimistic Offline Lock
      Active Recordは更新時にバージョン番号やタイムスタンプなどをチェックして、競合が発生したら例外を発生させる機能がああります(モデルにlock_versionというカラムを用意すると、自動的に楽観ロックをサポートする）
    • Pessimistic Offline Lock
      Active Recordは更新前にデータをロックして、他のユーザーがアクセスできないようにする機能があります（with_lockというメソッドを使うと、ブロック内で自動的に悲観ロックされる）
  • Base Patterns
    • Mapper
      Active Recordは、オブジェクトとデータベースのテーブルを一対一で対応付けて、データの操作を簡単にするパターンで実装しています
katzumikatzumi

Active Recordは、Data Source Architectural Patternsに分類されるパターンですが、他のパターンとも関連がある

Data Source Architectural Patterns以外のパターンで以下の様な関連がある

  • Domain Logic Patterns
    • Domain Model
      Active Recordは、ドメインモデルの意味表現に使われる要素として機能する
    • Row Data Gateway
      Active Recordは、データベースの行に対応したオブジェクトとして機能する
    • Table Module
      Active Recordは、データベースのテーブルに対応したモジュールでビジネスロジックを実装するパターンを有する
  • Object-Relational Behavioral Patterns
    • Unit of Work
      Active Recordは、オブジェクトの変更を追跡し、データベースに一括で反映するパターンを有する
    • Identity Map
      Active Recordは、同じデータベースのレコードに対応するオブジェクトを一意に管理するパターンを有する
  • Object-Relational Structural Patterns
    • Identity Field
      Active Recordは、オブジェクトに一意な識別子を持たせるパターンを有する
    • Foreign Key Mapping
      Active Recordは、オブジェクトの関連をデータベースの外部キーで表現するパターンを有する
  • Object-Relational Metadata Mapping Patterns
    • Metadata Mapping
      Active Recordは、オブジェクトとデータベースのマッピングは設定より規約（convention over configuration）で表現します
  • Web Presentation Patterns
    • Model View Controller
      Active Recordは、画面表示のロジックをモデル、ビュー、コントローラーに分離するパターンの中のモデルを担っています
katzumikatzumi

ActiveRecordパターンを実装した主要なフルスタックフレームワークとその機能名

  • Ruby on Rails

    • ActiveRecord
    • 説明
      Railsのデータベースアクセスの核となる部分であり、データベーステーブルに対応するモデルを作成し、データベースの操作をオブジェクト指向のインターフェースとして提供する

  • Laravel

    • Eloquent ORM
    • 説明
      Laravelのデータベースアクセスを担当するORM（Object-Relational Mapping）であり、ActiveRecordパターンを実装。Eloquentを使ってデータベーステーブルに対応するモデルを作成し、データベースの操作を行う

  • Django

    • Django Models
    • 説明
      Djangoのデータベースアクセスを担当する部分であり、ActiveRecordパターンを基にしたデータベースモデルを作成し、データベースとのインタラクションを提供

  • Symfony

    • Doctrine ORM
    • 説明
      Symfonyのデータベースアクセスを担当するORMであり、ActiveRecordパターンを採用。
      Doctrineを使ってデータベーステーブルに対応するエンティティ（Entity）を定義し、データベースの操作を行う

  • Yii

    • ActiveRecord
    • 説明
      Yiiのデータベースアクセスを担当する部分であり、ActiveRecordパターンを実装
      YiiのActiveRecordを使ってデータベーステーブルに対応するモデルを作成し、データベース操作を行う

  • Spring Boot

    • Spring Data JPA
    • 説明
      Spring Data JPAはSpringフレームワークの一部であり、JPA（Java Persistence API）を実装したデータベースアクセスライブラリです。
      Spring Data JPAを使うことで、ActiveRecordパターンを実装したデータベースモデルを作成し、データベース操作を行うことができる

以下はライブラリで提供されているORMライブラリでActiveRecordパターンに対応しているもの

  • Hibernate
    HibernateはJavaのオープンソースのORM（Object-Relational Mapping）フレームワークであり、データベースアクセスをサポートする
    HibernateはActiveRecordパターンを実装しており、データベーステーブルに対応するJavaのエンティティ（Entity）を作成し、オブジェクト指向的な方法でデータベースの操作を行うことができる

  • GORM
    GORMはGo言語のためのオープンソースのORMライブラリであり、ActiveRecordパターンを採用している。
    GORMを使うことで、データベーステーブルに対応するGoの構造体を定義し、データベースの操作をオブジェクト指向的に行うことができる

  • XORM
    XORMはGo言語のORMライブラリの一つであり、ActiveRecordパターンをサポートしている。
    XORMを使うことで、Goの構造体をデータベーステーブルにマッピングし、データベース操作を簡単に行うことができる。

katzumikatzumi

Active Recordは、Data Source Architectural Patternsに分類されるパターンですが、他のパターンとも関連がある

Data Source Architectural Patterns以外のパターンで以下の様な関連がある

  • Domain Logic Patterns
    • Domain Model
      Active Recordは、ドメインモデルの意味表現に使われる要素として機能する
    • Row Data Gateway
      Active Recordは、データベースの行に対応したオブジェクトとして機能する
    • Table Module
      Active Recordは、データベースのテーブルに対応したモジュールでビジネスロジックを実装するパターンを有する
  • Object-Relational Behavioral Patterns
    • Unit of Work
      Active Recordは、オブジェクトの変更を追跡し、データベースに一括で反映するパターンを有する
    • Identity Map
      Active Recordは、同じデータベースのレコードに対応するオブジェクトを一意に管理するパターンを有する
  • Object-Relational Structural Patterns
    • Identity Field
      Active Recordは、オブジェクトに一意な識別子を持たせるパターンを有する
    • Foreign Key Mapping
      Active Recordは、オブジェクトの関連をデータベースの外部キーで表現するパターンを有する
  • Object-Relational Metadata Mapping Patterns
    • Metadata Mapping
      Active Recordは、オブジェクトとデータベースのマッピングは設定より規約（convention over configuration）で表現します
  • Web Presentation Patterns
    • Model View Controller
      Active Recordは、画面表示のロジックをモデル、ビュー、コントローラーに分離するパターンの中のモデルを担っています
katzumikatzumi

PoEAAとは直接関係ないが、以下の記事がDomain Logic Patterns でのService Laryerと関係がありそうなので取り上げる

https://techracho.bpsinc.jp/hachi8833/2021_01_07/14738

Active Recordパターンできちんと扱える範囲を超えるような複雑な要素を扱うための定番の手法がまだないのです。幸いにも、オブジェクト指向における一般的な原則とベストプラクティスというものがあるので、Railsに欠けている部分にこれらを適用することができます。

上記のベストプラクティスがPoEAAで言及されているいくつかのパターンに該当すると思われる
該当するということはRailsのActiveRecordが単純にData Source Architectural Patterns以外のパターンの要素を持ち合わせていることの裏付けになると考えている

* Value Object
-> Base PatternsのValue Object

  • Service Object
    -> Domain Logic PatternsのService Layer
  • Form Object
    -> Web Presentation PatternsnのModel View Controller
  • Query Object
    -> Object-Relational Metadata Mapping PatternsのQuery Object
  • View Object
    -> Web Presentation PatternsnのModel View Controller
  • Policy Object
    -> Offline Concurrency Patterns?
    認可周りかなー
  • Decorator
    -> Web Presentation PatternsnのModel View Controller
katzumikatzumi

肥大化したモデルを分解するための7つの方法についてPatterns of Enterprise Application Architectureのパターンとの関連をまとめる

  • Service Object
    • Service Layerパターン
      Service Layerパターンは、ドメインロジックを表現するために、アプリケーションのビジネス操作を定義するレイヤーを導入するもの。
      Service Objectは、Service Layerパターンの実装方法の一つ
  • View Object
    • View Objectパターン
      Value Objectパターンは、不変で同値性に基づいて比較できるオブジェクトを定義するもの
  • Form Object
    • Data Transfer Objectパターン
      Data Transfer Objectパターンは、複数のデータを一つのオブジェクトにまとめて転送するために使用されるもの
      Form Objectは、Data Transfer Objectパターンの特殊なケース
  • Query Object
    • Query Objectパターン
      Query Objectパターンは、データベースへのクエリをオブジェクトとして表現するもの
  • Decorator
    • Decoratorパターン
      Decoratorパターンは、既存のオブジェクトに新しい機能や責任を動的に追加するものです。
  • Policy Object
    • Strategyパターン
      Strategyパターンは、アルゴリズムやビジネスルールをカプセル化し、実行時に切り替えることができるようにするもの
      Policy Objectは、Strategyパターンの応用
katzumikatzumi

https://panda-program.com/posts/how-to-read-pattern-books

記事が面白かったのでリンク

なぜなら、この書籍のおかげでバックエンドエンジニアとのコミュニケーションがスムーズになり、さらに自分が前から持っていた 「DDD 忌避症」が解消されたからだ。 PoEAA を読むことで、DDD の半分はパターン集であり、そのパターンも PoEAA が執筆された当時のものを参考にしているとわかったためだ。

DDDの半分がPoEAAのパターンになっている というのはそう思う。
それを理解することでクリーンアーキテクチャにも正しく向き合えそう。そんな読み込む際の心構えが書いてある

katzumikatzumi

PoEAAとSOLID原則の関連

  • Single-responsibility Principle（単一責任の原則）
    この原則は、クラスは一つの責任だけを持つべきで、変更の理由は一つだけであるべきというもの。
    この原則に従うと、コードの可読性や保守性が向上する。この原則に即しているパターンの一つは、Repository。
    Repositoryパターンでは、データアクセスロジックを専用のクラスに分離し、ビジネスロジックやプレゼンテーションロジックから独立させる。
    これにより、データアクセスロジックの変更が他の層に影響を与えないようになる。
  • Open-closed Principle（開放閉鎖の原則）
    この原則は、クラスやモジュールは拡張に対して開かれており、変更に対して閉じているべきというもの。
    つまり、既存のコードを変更せずに新しい機能を追加できるようにするべきということ。
    この原則に即しているパターンの一つは、Service Layer。
    Service Layerパターンでは、ビジネスロジックをサービスと呼ばれるクラスやインターフェースにまとめる。
    これにより、サービスを利用するクライアントはサービスの実装や内部構造に依存せずに、サービスが提供する機能を利用できる。
    また、サービスの実装を変更したり、新しいサービスを追加したりすることが容易となる。
  • Liskov Substitution Principle（リスコフの置換原則）
    この原則は、サブクラスはそのスーパークラスと置換可能であるべきというもの。
    つまり、サブクラスはスーパークラスが満たす契約（仕様や振る舞い）を継承し、それを遵守するべきということ。
    この原則に即しているパターンの一つは、Lazy Load。
    Lazy Loadパターンでは、オブジェクトが必要になるまでそのオブジェクトが参照するデータを読み込まないようにする。
    これにより、パフォーマンスやメモリ使用量を改善できる。
    Lazy Loadパターンでは、オブジェクトがデータを読み込むタイミングや方法を隠蔽し、オブジェクトの利用者から見たら通常のオブジェクトと同じように扱えるようにする。
    これはリスコフの置換原則に従っている
  • Interface Segregation Principle（インターフェース分離の原則）
    この原則は、クラスは自分が利用しないメソッドを持つインターフェースに依存するべきではないというもの。
    つまり、インターフェースは特定の目的に絞って設計するべきということ。
    この原則に即しているパターンの一つは、Unit of Work。
    Unit of Workパターンでは、データベースに対する一連の操作を一つのトランザクションとして管理します。これにより、データの整合性やエラー処理を効率的に行える。
    Unit of Workパターンでは、データベースに対する操作を抽象化したインターフェースを定義し、それを実装したクラスを提供する。
    これにより、データベースの種類や実装に依存せずに、データベース操作を行える。
    また、インターフェースは必要なメソッドだけを持つように設計される。
  • Dependency Inversion Principle（依存性逆転の原則）
    この原則は、高レベルのモジュールは低レベルのモジュールに依存するべきではなく、両者は抽象に依存するべきというもの。
    つまり、具体的な実装ではなく、インターフェースや抽象クラスに依存するようにするべきということ。
    この原則に即しているパターンの一つは、Dependency Injection。
    Dependency Injectionパターンでは、オブジェクトが必要とする他のオブジェクト（依存オブジェクト）を外部から注入することで、オブジェクト間の結合度を低くする。
    これにより、オブジェクトの再利用性やテスト性が向上する。
    Dependency Injectionパターンでは、依存オブジェクトはインターフェースや抽象クラスで定義されており、具体的な実装は外部から指定される。
katzumikatzumi

bobおじさんの言及が面白かったので紹介

https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects

So applications built around ActiveRecord are applications built around data structures. And applications that are built around data structures are procedural—they are not object oriented. The opportunity we miss when we structure our applications around Active Record is the opportunity to use object oriented design.

つまり、ActiveRecordを中心に構築されたアプリケーションは、データ構造を中心に構築されたアプリケーションということになる。データ構造を中心に構築されたアプリケーションは手続き型であり、オブジェクト指向ではない。ActiveRecordを中心にアプリケーションを構成すると、オブジェクト指向設計を使う機会を逃してしまう。