エンティティ モデル
エンティティにとって最も基本的な責務は、ふるまいが明確で予測可能になるよう、連続性を確立することである。これが一番うまくいくのは、余計なものがない状態が保たれている時だ。属性やふるまいに集中するよりは、エンティティオブジェクトの定義を、最も本質的な特徴にまで削ぎ落とすこと。(第二部第5章より)
「設計とプロセス」で読んだように、DDDは、アジャイルプロセスで開発することを前提としています。
イテレーティブ（反復的）にモデルを成長することができるので、上記のように、まずエンティティを最も本質的な特徴にまで削ぎ落とすようなことも可能となります。
エンティティの本質的な特徴とは
- エンティティを識別するもの
- エンティティを検索し突き合わせるのに通常使用されるもの
- その概念にとって本質的なふるまいと、そのふるまいが必要とする属性
上記からエンティティとその属性を見つけ出し、さらにそれらの属性が別のエンティティや値オブジェクトに移動できないかを検討します。
"削ぎ落とす"というのはそういうことなんですね。
設計・開発にとって、必要なものを付け足していくというのは普通のことですが、それをわざわざ削ぎ落としていくことにDDDの真髄があるような気がしますね。
例
たとえば、注文の例で言えば(全然属性が足りないですが・・・あくまで例として)、まず上記のようにモデリングをしたあとに、削ぎ落とす作業をします。
- 注文IDはエンティティを識別するものなので残します。
- 配送先住所は問い合わせがあった場合に検索に使うので残します。
- 商品名で注文を検索することはないので移動します。
- 合計金額で注文を検索することはないので移動します。
というわけでこうなりました。
注文の合計金額も注文の本質的なふるまいですが、注文合計金額というモデルを分けたのでふるまいをそちらに移動しています。
商品も商品コードで識別していますので、ここのエンティティの検討も必要になりますね。
明日は実装面を見てみたいと思います。