エンティティ

｢ドメイン駆動｣の第二部を一読しました。発注処理アプリケーションを少しずつ組み立てていく様子を追うことができ、どこでどういう問題があり、どういうパターンを使って解決すべきかという流れを追えて、非常に面白いなと感じつつ、そのパターンに関する理解が浅いため深く理解しきれていないのが現状です。だた、｢Evans DDD｣や｢Fowler PoEAA｣への興味が深まったのは事実です。これらの本で学び終えたあと本書を再読すれば、多くの発見をすることができるであろうと予測しています。
本書のいままでの部分で最も印象に残った説明が、｢エンティティについて話すべきとき｣というトピックでした。｢ドメインモデル｣とは何ぞやということについては、まだまだしっかりと把握できていない状態ですが、このトピックで書かれていることは、それに対する大きなヒントになりそうだったので、その部分を引用しておきます。

ドメインでは、時間を越えてあるものを追跡できることが大切だ。名前や住所を変えても、顧客は同じ顧客であり、私たちが追跡したいのもそれだ。しかし、顧客の保証人が変わったら、もう保証人は追跡すべきものではなくなる。顧客は、エンティティの典型的な例である。繰り返しになるが、エンティティとは、値ではなく、アイデンティティによって追跡すべきものだ。
エンティティではないものの極端な例として、42という整数について考えてみよう。42の同一性には誰もこだわらない。気になるのは値だけだ。値が変わったら、変更された42だなどとは考えない。古い値とは無関係な新しい値である。42は値オブジェクト：Value Objectであり、エンティティではない。
私たちのドメインにこの極端例を持ち込むと、CustomerのReferencePersonをアイデンティティで管理しても無意味だと言える。私たちにとって、それは値で管理しなければ意味がない。

何にフォーカスを当て、それにどのような情報を持たせ、どのような処理をさせるのか。その役割をはっきりさせた上で、そういったものどうしの関連性を組み立てていく。こういった試行錯誤を繰り返しながらソフトウェアを開発していくのが｢ドメイン駆動｣なのかというのが、今のところの自分の理解です。｢Evans DDD｣の冒頭の数章でも、そのような過程が述べられています。具体的な手法については、これからという感じですが、最近手に入れた｢Fowler PoEAA｣をパラパラめくってみると、非常に中身の濃い議論が展開されていそうな感じだったので、今から読むのが楽しみです。