ドメイン駆動設計 Entity と Value objectについて

Question

ドメイン駆動設計 Entity の作成方法

ここに質問の内容を詳しく書いてください。
（例）PHP Laravelを用いてドメイン駆動設計に基づいた開発をはじめました。
少し疑問が生じたので、質問させてください。

理解した内容(質問)

Entity を作成する際、DBのテーブル名をEntityとして定義し、
テーブルに存在するカラム名を、それぞれ値オブジェクトとして定義していました。
Entity(テーブル)のコンストラクタに値オブジェクト(カラム)を引数として渡すことで、
Repositoryでの永続化を行いやすくなると考えていたのですが、間違っていますでしょうか？

データベースの例

TABLE:
    companies

COLUMNS:
	id
	company_name
	company_domain
	company_mail
	original_id

試したこと

というテーブルがあった場合

companiesテーブルをEntityとして、

company_name, company_domain, company_mail, original_idをそれぞれValueObjectとして定義していました。

もし違うのであれば、
みなさんがEntityを作成する際の基準などを教えていただきたいです。

Answer 1

Entity(テーブル)のコンストラクタに値オブジェクト(カラム)を引数として渡すことで、

Repositoryでの永続化を行いやすくなると考えていたのですが、間違っていますでしょうか？

ドメインモデル設計のアプローチとしても、RDBのテーブルというインフラストラクチャ層にドメインが依存する構造になるという点においても「間違ってる」という回答になるでしょう。

https://codezine.jp/article/detail/10038

DDDで設計を始めてみると、データの格納方法ばかり気になってしまうことがよくあります。このようなERモデリング（テーブル構成とリレーション関係）を先に検討されたエンティティは、DB項目のプロパティしか存在しない機能不足なモデル「ドメインモデル貧血症」になりがちです。ドメインモデル貧血症とは、オブジェクト指向設計の基本である「データと処理を一緒に取り扱う」ことを行わない、単なる手続き型設計のことです。一見、ドメインモデルと同じような構造を持ちつつも、オブジェクトの「振る舞い」が不足している状態を指します。

（以下略）

Comments

[rgb_nk]

gentaro様
速やかな回答と、参考リンクも共有頂き有難うございます。
そちらのリンクは以前拝見したことがあるのですが、私の実力不足で理解が及びませんでした。
今回私がサンプルとしてのせたtableの場合、値オブジェクト飲みで良いということでしょうか？
gentaro様は普段、Entityとして定義する際何を意識していますでしょうか？
会社情報も変わることがあるので、ライフサイクルを持っていると勘違いしておりました。

[gentaro]

いや、「テーブルからエンティティを定義する」という考え方がそもそも違う、という話です。引用部分もその事が書いてあります。
リボジトリを導入する利点は、永続化に関する影響範囲をリボジトリ以下のインフラストラクチャ層に隠蔽することにあります。
それなのに、インフラストラクチャ層のデータ構造（テーブル構造）をそのままドメインモデルとして利用してしまうと、この隠蔽を壊すことになります。
ドメイン駆動設計をやりたいのであれば、データベースなどという詳細については後回しで、問題領域（ドメイン）をモデリングするところから始めるべきでしょう。アプローチの順序が違うということです。

[gentaro]

付け加えるなら、例えばドメインモデルが変更されたから永続化層(テーブル構造など)が影響を受けて変更されるのはアリですが、逆はナシです。
テーブルの正規化や非正規化など、永続化層のみの都合でアプリケーション全体が影響を受けてはいけません。

[rgb_nk]

なるほど大変わかりやすいご回答ありがとうございます。
今になり理解できました。
何度も初歩的な質問してしまい申し訳ございませんでした。