when-to-wrap-primitives

プリミティブ型ラップ判断ガイド

プリミティブ型をラップすべきか否かは、コスト対効果で判断する。盲目的にラップするのも、 一切ラップしないのも、どちらも設計の失敗である。

前提: Value Objectの定義は1つではない

「Value Object」という用語は文脈によって意味が異なる。議論やレビューで混乱が生じる主因である。

定義	出典	スコープ	核心
一般的定義	Wikipedia等	最も広い	同等性がIDではなく値に基づくオブジェクト
PofEAA定義	Martin Fowler	実装パターン	IDに基づかず値で等価判定される小型オブジェクト。別名参照問題を避けるため不変が推奨
DDD定義	Eric Evans	ドメインモデリング	PofEAA版の特性をすべて備えた上で、ドメインの概念を計測・定量化・説明し、不変条件と副作用のない振る舞いを持つドメインオブジェクト

DDD版はPofEAA版のextends

DDD版VOとPofEAA版VOは独立した概念ではなく、特化（specialization）の関係にある。

特性	PofEAA VO	DDD VO
値による等価判定	必須	必須（継承）
不変性	推奨	必須（強化）
ドメイン不変条件	ー	必須（追加）
ドメイン振る舞い	ー	必須（追加）

つまり：

• DDD VO IS-A PofEAA VO → すべてのDDD VOはPofEAA VOでもある
• PofEAA VO IS-A DDD VO → 成立しない（Ruby HashはPofEAA VOだがDDD VOではない）

DDD版は「値で等価判定される」「不変である」というPofEAA版の特性を前提として含んだ上で、 ドメイン固有の要件を追加したものである。2つの定義を並列に見ると、DDD版が PofEAA版の特性も持っていることを見落としやすいので注意。

チーム内では「PofEAAのVO」「DDDのVO」のように文脈を明示して使い分けるべき。

本スキルの立場

本スキルでは、「プリミティブ型をドメイン固有型でラップすべきか」という実践的判断に焦点を当てる。 VOの定義論争には立ち入らず、ラップすることで得られる具体的な利益がコストに見合うかで判断する。

2つのアンチパターン

Primitive Obsession（プリミティブ型への固執）

すべてをString/int/floatで表現し、ドメインの制約がコードに表れない。

fn transfer(from: String, to: String, amount: f64)
// fromとtoを取り違えてもコンパイルが通る
// amountが負でもコンパイルが通る
// 通貨の概念がない

症状:

• 同じプリミティブ型の引数が2つ以上並ぶ
• バリデーションロジックが呼び出し側に散在
• 「この文字列はメールアドレスのはず」という暗黙の前提
• 単位の取り違え（メートルとフィート、円とドル）

Value Object Obsession（過剰なラップ）

すべてのプリミティブ型を機械的にクラスで包み、複雑性だけが増す。

class CustomerFirstName(value: String)
class CustomerLastName(value: String)
class ShippingFirstName(value: String)  // CustomerFirstNameと何が違う？
class ShippingLastName(value: String)   // 同上

症状:

• 不変条件やドメインロジックを持たない「ただのラッパー」が大量に存在
• 文脈ごとに別の型を作るが、中身のバリデーションは同一
• 型変換のボイラープレートがドメインロジックより多い
• 新規メンバーが型の森で迷子になる

判断フレームワーク

5つの判断基準

プリミティブ型をラップすべきかを以下の基準で評価する。 1つでも強くYesならラップを検討。複数Yesなら強く推奨。すべてNoならラップ不要。

基準1: ドメイン不変条件があるか

その値に「常に満たすべき制約」があるか？