0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

モデルについて色々調べてみた(ついでにLaravelとDDD)

Last updated at Posted at 2025-03-05

最近色んな「モデル」という言葉に出会ったので、まとめてみました。

データモデルの種類

データモデルは、用途に応じて以下の3種類に分類されます。

概念データモデル

現実世界の事象やプロセスを抽象化して、データの構造を表現するモデル。

物理データモデル

データがデータベース管理システム(DBMS)内でどのように格納され、アクセスされるかを定義するモデル。

論理データモデル(諸説)

こちらは特に定義が揺れがちなモデルでした。
基本的には、データの構造や関係を定義するモデルですが、データベースを巻き込むかどうかの考え方が分かれていました。

ネットで調べた感じ

  • データ総研の系記事では、「論理データモデルはデータベースの構造や操作を定義する」とされている。
  • NTTデータの記事では、「論理データモデルはビジネスのデータ構造のみを表現し、DBMSに依存しない」としている。

という風に、データベース巻き込み型と、巻き込まない型の論理データモデルがあります。

AWSの解説では、論理データモデルには中間テーブルの概念がなく、物理データモデルには存在するため、データベース巻き込まない派のようです。

共通で、論理データモデルはエンティティクラスの立ち位置といえそうでした。

参考: AWSの論理データモデルと物理データモデルの違い


LaravelのEloquentモデル

最近触る機会があったLaravelでは、内部にEloquentが提供してくれるModelがあります。これはどんなモデルでしょうか。

Laravel公式の説明では、

Laravelには、データベースとの対話を楽しくするオブジェクトリレーショナルマッパー(ORM)であるEloquentが含まれています。Eloquentを使用する場合、各データベーステーブルには対応する「モデル」があり、そのテーブルとの対話に使用します。

とされています。

つまり、Eloquentのモデルは「データベース巻き込み型の論理モデル」と言えそうです。


DDD(ドメイン駆動設計)におけるモデル

『ドメイン駆動設計モデリング実践ガイド』によると、

モデルにはさまざまな種類があり、目的によって使い分けられます。DDDの文脈で頻出し、混乱しやすいのは次の2種類のモデルです。
・ドメインモデル:ドメインの間題を解決するためのモデル
・データモデル:データの永続化方法を決める(永続化方法の効率化という問題解決
を行う)ためのモデル

これを3種のデータモデルに当てはめて整理すると、

  • データモデル = 物理データモデル or データベース巻き込み型の論理データモデル
  • ドメインモデル = 概念データモデル かつ 問題解決のロジックを持った論理データモデル

という形になりそうです。


論理データモデルとデータベース知識の漏れ

ここまで調べた感じ論理データモデルの解釈は、データベースの知識が漏れるかどうかが大きなキーになりそうでした。

  • ドメイン駆動・ユースケース駆動等(現実世界・概念寄り)
  • データベース駆動(データベース構造に影響を受ける)

という違いとも捉えられると思います。
(データベース駆動という言葉は自分が気に入って使っている言葉です。)

またプロジェクトで使い分けをするならば、
例えば、
既存のビッグデータを利活用するシステム → データベース巻き込み型の論理モデルでエンティティを定義するのは納得感ある。
現実世界のユースケースを重視するシステム → 概念・ドメイン駆動のアプローチが適している。(こちらが一般的)

というパターンが考えられると思います。

私の意見としては、
一般的なシステムにおいて、データベースを操作することは当然ありますが、現実世界のユースケースを実現するために最終的に操作するためのものとして認識しています。
リポジトリパターンを採用するなどして、データベースの知識は、特定のクラスに閉じ込め、
インターフェイスやユースケースの層には、データベースの知識は漏れ出さない形が、一般的には理想になると言う認識を持っています。

(とはいえ、論理データモデルとテーブル構造が一致してしまうことも多いイメージです)

データベースの知識漏れの注意

仮にデータベース巻き込み型の論理データモデルを採用したとしても、インターフェース層やコントローラまで、このモデルを持ち込むのは危険です。

サービスのユーザーやAPIを利用するフロントエンドが、実現したいユースケースの中で、データベースの構造を知る必要は当然ありません。

APIレスポンスとして、ユーザーやフロントエンドに対して必要なデータを返したいときに、データベースの構造がレスポンスに影響する必要も当然ありません。

Laravelの場合だと、テーブルと紐付くResourceクラスがありますが、これをレスポンスとして使うのは、上記の理由で個人的には避けた方が良いと思います。

さいごに

メモ書きからAIにまとめて貰って、そこからたくさん自分で加筆したので、文体がやや乱れている気がします。

英語としてのモデルは「型。模型。」
modelの語源は「modus」で「型・適量・様式」などみたいです。

「モデルさん」は、型とかお手本になるみたいな意味?模型みたいって意味?なんですかね。

「アイドル」は、「偶像、崇拝される人や物」で、空想上のもの感がありますね。

それで言うとアイドルの方が格上な感じしますが、昨今は地下アイドルって言葉もあり、今の自分の感覚としてはモデルの方が格上です。
はい。余談失礼しました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?