Chapter Five. A Model Expressed in Software (p.81) †
要約 †
- 実装にあたって基礎を再構築しておく必要がある。モデルと実装との結合は詳細化された水準においてなされなければならない。この章ではモデルの各要素に焦点を当てる。
- まずは関連"Associations"についての議論から。関連を実装するのは予想以上に難しい。関連について考察することで、実装時になされる詳細な決定事項がMODEL-DRIVEN DESIGNを実現するにあたって、どれほど決定的な影響を与えるのかが分かる。
- 次にオブジェクト自体について。ここではモデルを表現する要素の三つのパターンを明確に切り分ける。その三つとはすなわち、ENTITIES、VALUE OBJECTS、そしてSERVICESである。
- ドメインの概念を表現するオブジェクトを定義することは、一見分かりやすいことのようだが、実際には重要な課題を秘めている。ある種の切り分けはモデルの構成要素の意味を明らかにするし、また、その切り分けは多くのデザインプラクティスと結びついている。
- 「あるオブジェクトは、連続性と同一性に基づいて何かを表現しているのか？あるいは何かの状態を表現するのは属性なのか？」これが、ENTITYとVALUE OBJECTの基本的な違いである。
- ドメインには、オブジェクトとしてよりもむしろ活動"actions"や操作"operations"によって表現する方が明確になる局面も存在する。こういった局面は、ENTITYやVALUE OBJECTに責任を押し付けるよりも、SERVICESとして表現するのが一番よい。
- オブジェクトモデルの純粋さを妥協しなければならないこともあるが、そのような現実への対処方法についても触れる。
- 最後にMODULEについて議論することで、「デザイン上のあらゆる決定事項はドメインに関する何らかの洞察"insight"に裏づけられなければならない」というポイントに立ち返る。MODEL-DRIVEN DESIGNにとってMODULEはモデルの一部なのであり、ドメインについての概念を反映しなければならないものなのである。
- これらの概念は真新しいものではなく、そこから導き出されるモデリングとデザインの関心事についても過去に論じられている。しかし、これらを現在の文脈に位置づけることは、ドメイン駆動デザインの詳細な構成要素を作る上での助けになる。また、基本原則という考え方は、妥協しなければいけない時に、本質からずれないようにしてくれるものだ。
担当者のつぶやき †
- Chapter Fiveの見通しを立てるのによさそうだったので勝手ながら追加しました。
みんなの突っ込み †
