ユビキタス言語は用語ではなく言語

Domain-Driven Design Distilled (English Edition)というコンパクトにDDDを要約した本を読んでいたら何となく感じていたことが書いてあったので抜粋します。

Is your Ubiquitous Language formed from a set of well-known nouns? Nouns are important, but often software developers put too much emphasis on the nouns within a domain model, forgetting that spoken language is composed of far more than nouns alone. 
あなたのユビキタス言語は、よく知られた名詞の集合から形成されていますか?名詞は重要ですが、しばしばソフトウェア開発者はドメインモデル内の名詞に過度に重点を置き、話し言葉が名詞だけでなくもっと多様な要素で構成されていることを忘れがちです。 Chapter 2. Strategic Design with Bounded Contexts and the Ubiquitous Language

ユビキタス言語は、単なる用語集ではなく、設計者とドメインエキスパートが対話に使うことのできる言語なので名詞だけでなく、動詞、副詞、その他の文法要素も含まれる。

この言語機能を使って具体的なシナリオ(文章化)を定義して議論することで、モデリングの改善に繋げることができる。

例として本書ではスクラム開発のユビキタス言語を使いシナリオを作成することで「スプリントに項目をするのは誰か?」という問題を発見している。

しかし用語集の作成自体がアンチパターンとは思っていなくて、実際に私も用語(語彙)をまとめたドキュメントを作る。この時の用語とソースコードの乖離を解決するためにリファクタリングをしていきたいのだけど、あまりいい戦略を持ってないので誰か教えて欲しい(DBのtable名とclass名をどう変更して管理していくのかというのをいつも悩んでる)。

BDD

このシナリオをBDDのツールでコード化して検証できるよというところまで書いてあるが、個人的にはあまりそこに成功体験がない。

なんでだろうと少し考えたがシナリオ(behavior)をコード化するところまでは概ね満足していたが、モデリングの運用が未熟でメンテナンスに振り落とされたということなのかもしれない。

あとシナリオを実行するということが=ユーザー環境なので実行環境が重厚で運用に苦労するというのもある。「System tests have failed」を読んだ人は共感できるだろう。