ユビキタス言語は発見するものでなく設計するものであると思う

きっかけ

blog.magnolia.tech

id:magnoliak さんがおもしろそうな話をしていたので乗っかってみた。

きっかけとなったメタツイート

って言われたのでブログに書いとくことにする。

ブログ書くの何年ぶりだ…

TL; DR

まあ、言いたいことはだいたい以下のツイートにまとまっている。

ユビキタス言語

僕のブログを読みにくるような人にユビキタス言語とは何かって説明するのは釈迦の説法だと思うけど、一応『エリック・エヴァンスのドメイン駆動設計』（以下、エヴァンス本）におけるユビキタス言語の説明を引用しておく。

モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 言語を使う上で問題があれば、代わりの表現を用いて実験することで、問題を取り除くこと。そうした表現は代わりとなるモデルを反映している。そこで、新しいモデルに合わせてコードをリファクタリングし、クラス、メソッド、モジュールの名前を変更すること。会話の中で用語が混同されていたら、普通の単語の意味について認識を合わせるのと同じやり方で解決すること。 ユビキタス言語における変更は、モデルに対する変更であると認識すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に意義を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。

（第2章 コミュニケーションと言語の使い方）

ユビキタス言語が設計の対象であるとはどういうことか

ユビキタス言語とは、ユーザー（もしくはエヴァンス本の言葉で言えばドメインエキスパート）の要求や彼らの言葉遣いの中から「発見」するものだと思われている節があると思う。

それはたとえば、伝統的なオブジェクト指向分析の「ユーザーの使う単語のうち、名詞をオブジェクト（もしくはクラス）に、動詞をメソッドにマッピングする」というような、すでに存在する語彙の分類方法や構造化手法のようなものと捉えられてるのではないだろうか。

無論それはそれで重要なプロセスではあると思うけど、それだけではなくて、今回話題になった「本来のビジネス要求に存在しなかった抽象を示す語彙」を見出してそれをユーザー（or ドメインエキスパート）と共有することでさらにコミュニケーションを円滑にすることができると思うし、それがよい抽象であればそれを使ったより上位の設計、つまり抽象に対して具象を創り出す行為をユーザ（ドメインｒｙ）に委譲することができる。

もちろん「よい抽象である」という前提を満たすことが難しいのだけど、だからこそそれが重要な設計と言えるのだと思う。

電気回路の専門家は電源と抵抗、それに容量とインダクタがあれば自分の欲しい回路を自分で組むことができるし、会計や税務の専門家は仕訳と元帳があれば自分たちのビジネスに応じた財務戦略や税務戦略を考えることができる。僕たちが設計するべきは具体的な電気回路や財務諸表でなく、電源や抵抗/容量/インダクタ、あるいは仕訳や元帳という抽象であるべきだと思う。もちろん電気回路や会計の世界では僕たちが設計するまでもなくすでにそれらの語彙が揃っているわけではあるけど。

まとめ

よい設計とは、別の誰かの設計に対するメタ設計であるべきだと思う。つまり、僕たちが見出した抽象を別の誰か（たとえばドメインエキスパｒｙ）が具象化することでその人自身のニーズを満たすことができる場合、その抽象はとてもよいものだと言える。よい抽象は当然普段の会話や議論の中で自然に使われると思うし、ユビキタス言語になるというのはそういうことなのではないだろうか。

エヴァンス本にも次のように書かれている。

モデルに基づいたこの言語は、開発者の間で使用されなければならない。それも、システムにおける成果物を記述するためだけでなく、タスクや機能を記述するためにも使われなければならないのだ。開発者が使うのと同じモデルによって提供される言語は、開発者とドメインエキスパートが互いに意思疎通をする際にも用いられなければならないし、ドメインエキスパート同士が要件や開発計画、あるいは機能を伝え合う際にも用いられなければならない。言語が広く使用されるほど、理解もよりスムーズに進むようになるのだ。

（第2章 コミュニケーションと言語の使い方）

つまり、成果物の説明には使われるが、機能やタスクの説明には DB の話やインフラの話をしなければならない場合、まだそのチームは十分な語彙を獲得できているとは言えないのではないだろうか。

ただ、Twitterにも書いた通り、これには勇気がいる。ユーザーが普段使ってない言葉を自分で作り出して、それを使ってもらおうというわけなので当然道のりは長いし、批判にさらされることだってある。ユーザーが使っている言葉をそのままクラス名やメソッド名にするほうが心理的にははるかに楽だと思う。でも、だからこそ、挑戦のしがいがあるんじゃないか。