• 追加された行はこの色です。
• 削除された行はこの色です。
• こうしておけばよかった/設計/バリューオブジェクトの作成を徹底する へ行く。
• こうしておけばよかった/設計/バリューオブジェクトの作成を徹底する の差分を削除

#author("2018-09-09T07:11:35+00:00","default:haruki","haruki")
#author("2018-09-09T07:12:21+00:00","default:haruki","haruki")
* キーワード [#c9c1d06a]
- バリューオブジェクト
- ドメインオブジェクト
- データマッピング

* 何か [#ic91a126]

バリューオブジェクトの作成を徹底する。

* なぜか [#rbc1359a]

ドメインオブジェクトの属性をすべてバリューオブジェクトで表現しようとするとクラス数はかなり増える。期間に収まらないかもしれないと思ったことと、理解されず説得する手間を惜しんだことで、属性値はプリミティブな型でもつようにした。

しかし、入力の値をモデル用の値に、DBの値を表示用の値にマッピングする都合はある。この場面で安全なマッピングをするために、結局は変換用のオブジェクトをかますように実装した。

用途に向けた変換のためのオブジェクトを作成するくらいなら、用途に応じたオブジェクトがあった方が分かりやすくてよかった。さらには、変換用のオブジェクトは実装上省略してしまうことができてしまうので、バリューオブジェクトを定義するより不安定なものにしてしまった。

* どのように [#r4b394b7]

ドメインオブジェクトの属性はバリューオブジェクトで表現することを基本にする。

例外でプリミティブな型を使用する場面は（手間がかかる都合以外）おそらくない。手を抜くことを考えるとすれば、「昼食代」「タクシー代」などを「料金」型にしてしまうくらいまでにしたほうがいいと思う。それでも特有の振る舞いがあるならやはり分割する必要はある。

* 反省 [#eda1f2be]

手を抜いてよいところとそうでないところは見極める。

ドメインオブジェクトを設計しておきながらバリューオブジェクトによる表現をサボるのは、一貫性を欠く悪手である。