データ／レコード中心系
✅ 概要
この系統は、データベースのテーブルやレコード構造を中心にアプリケーションを設計するスタイル を扱う。
- 「1 テーブル = 1 クラス（または 1 モデル）」という発想
- ビジネスロジックは主にデータ構造の近く、もしくはサービス関数に置かれる
- オブジェクト指向のドメインモデルよりも、RDB のテーブル設計が強く前面に出る
代表的なスタイルは次の 3 つ。
✅ なぜこの系統が生まれたか（歴史・背景）
- RDB と SQL が企業システムの中心となり、「データベース設計 = システム設計」と見なされることが多かった
- OR マッピングのコストを下げる必要があった
- Web フレームワーク（特に Rails）の普及により「モデルクラス = テーブルラッパ」というスタイルが広まった
- オブジェクト指向の複雑なモデリングよりも、スピードと現実解 を優先した設計が求められた
✅ 解決しようとした問題
- テーブルとオブジェクトの変換（O/R マッピング）の手間を減らしたい
- CRUD を素早く実装したい
- ビジネスロジックがそれほど複雑でなく、テーブルに近い形で表現しても問題ない
- 小〜中規模の業務アプリで「過剰なドメインモデリング」を避けたい
✅ この系統に属するスタイル
● Active Record
- テーブル 1 つにつきクラス 1 つを割り当て、
- 行 = インスタンス
- カラム = プロパティ
- INSERT / UPDATE / DELETE / SELECT をメソッドとして持つ
- Rails の
ActiveRecordが典型例
● Table Module
- テーブル単位でロジックをまとめるモジュール
- 集合としてのテーブル（複数行）に対する操作をモジュール関数として表現する
● Anemic Domain Model（貧血モデル）
- 「データクラス（プロパティのみ） + サービスクラス（振る舞い）」という構造
- データ中心スタイルの「行き過ぎた形」として、しばしばアンチパターン扱いされる
✅ 他の系統との関係
- A. 非構造〜初期系（Transaction Script） の自然な発展先として現れたスタイル群
- C. レイヤード／ドメインモデル系 とはしばしば対比される（データ中心 vs ドメイン中心）
- DDD やリッチドメインが必要な領域では限界があるが、CRUD 中心のアプリでは現実的な選択肢になる
✅ どんな時に参考になるか
- フル DDD や Hexagonal は重たいが、 ある程度の秩序を持った CRUD アプリを作りたいとき
- Rails のようなフレームワークを前提にした設計を整理したいとき
- 「貧血モデル」がなぜ問題になるのか、どこまでが許容できるラインかを考えたいとき
この系統を理解することで、 「現実的な CRUD アプリ」と「本気のドメインモデリング」の境界 を見極める助けになる。