ユビキタス言語は概念群の凝集である

第４回ドメイン駆動設計読書会@大阪の別の方の感想文を読んで、なるほどと思ったのでメモ。
ラフなメモ書き。

【元ネタ】
PHPメンターズ -> Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation

凝集度を高める　：　クラスもパッケージもコンテキストも「ドメインの視点」で凝集すべし | システム設計日記

sdi - Page: redbook-10　「理論編-9　経営過程」 を読む

(引用開始)
モデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になってはいます。しかし、もう少しブレの無い言葉で表現しておいた方が良いように思います。ここで、ソフトウェア工学で使われてきた「凝集度」という言葉を使えば、「概念群の凝集度」という視点で置き換えられるのではないかと私は考えます。この捉え方はすでに増田亨さんのブログでも触れられています。ドメイン駆動設計の後半では、蒸留カテゴリの中に凝集は繰り返し現れます。
(引用終了)

ユビキタス言語となった設計図は僕はまだ見たことがない。
だから、モデルの理想郷として考えてみる。

「ドメイン駆動設計」では貨物輸送システムの例が何度も出てくる。
普通のオブジェクト指向設計ならば、名詞をそのままクラスにして、その関連を結んで、クラス設計にしてしまう。
しかし、それは浅いモデル。

貨物輸送システムで実装したい機能要求を顧客から何度も引き出してみると、たくさんの業務ロジックが出てきて、その内容をクラス図に反映していく。
その過程は、業務ロジックをクラスの1メソッドで実装する作業ではなく、あるドメイン(関心事)の凝集度を上げて、本質的なドメインを編み出すことにある。
その作業そのものが、「蒸留」という作業なのだろう。

その「蒸留」という作業において、責務のレイヤーパターンを使えば、意思決定支援層にオーバーブッキングポリシーが出てくるのが分かる。
普通のオブジェクト指向設計では、オーバーブッキングポリシーという業務ロジックだけのクラスは出てこないだろう。
おそらく、アプリケーションのサービスクラスに、IF文やFor文が混じったべた書きの長いロジックになってしまうだろう。

深いモデルにするには、クラスは単なる名詞ではなく、業務ロジックやビジネス上のお金のやり取りも反映したものにすべき。
そのためには、やはり何らかの視点が必要。

その視点の一つが「責務のレイヤ」パターンであり、Policy-Control-Operationという考え方であり、T字型ERで言う事業過程・管理過程・組織過程の分類でもある。

そして、貨物輸送システムがビジネスで役立つシステムになるには、最終的には、お金のやり取りを具現化する「船荷証券」という権利をやり取りすることになる。
そこまで行き着いて、初めて、深いモデルになる。

深いモデルは、現れるクラスの凝集度が高い。
深いモデルになって初めて、モデルはユビキタス言語になる。