値オブジェクト
Value Objectについて整理しよう - Software Transactional Memo
値オブジェクト(Value Object)についての誤解が広まっているので、整理するための記事
自分も、怪しげな写像と直接的な写像などでプリミティブ型よりもクラス化したValueObjectをどんどん作ろう思考になっていた時期があるので、バランスを取るための批判として学習できた。
本当にドメインの語彙上での値が専用のクラスを持つに値するほど複雑なロジックを要するのであればもちろんそれを作るべきであるが「すべての語彙をValue Objectに包む事」自体を目標にしているうちはその必要性に迫られていない。YAGNI(You ain't gonna need it)原則に従い、本当に追い出すべき複雑性が実際に現れるまでは無用なリファクタリングをすべきではない。
@kawasima: Value Objectの話、整理してみました。
やってみて気づいたが、Primitive Obsessionの対策として、「Value Object」って用語を不用意に使わない方がいいな、と思いました。
https://pbs.twimg.com/media/FSdpOiWaQAAH5oc.jpg
以下は、2020年にDDD(Domain-Driven_Design) を学んだ時の理解
プリミティブ型よりもドメインにあった値オブジェクトを作る
int の数値よりも、Money型などを作る
ついついプリミティブ型を使いたくなるが、システムを育てることを考えたらドメインに特化した型を作って境界づけていったほうがよい
プリミティブ型は汎用性が高すぎて表現力が弱い
性質
不変
不変であることは条件ではない。実装上の不注意を減らすテクニックの一つ
交換が可能
等価性によって比較
事前条件、事後条件をチェックできる
これは別の値オブジェクトの文脈ではなく、オブジェクト指向の文脈
３文字以上とか、１０００未満になるとかのルールは、都度if文で判定するよりも値オブジェクトの中で持ったほうが管理しやすい
あちこちに条件判定文が散在すると、DRY原則を守りづらくなる
自分でテストを作れる