この記事は、Greg Young氏のブログ記事"BDD and the Shared Language"を、氏の許可を得て翻訳したものです。（原文公開日：2007年10月16日）
ここ数ヶ月というもの、私はすました顔でここに座り、BDDには自分にとって理解すべきようなものは何もない、と言ってきました（そして同じような意見の人とも会ってきました）。BDDは単にTDD+DDDであり、このコンセプトになじみがない開発者に教えるのが簡単なように組み替えられただけだというのです（Aaron Feng氏の優れた説明や、Raymond Lewallen氏によるより詳細な議論によればですが）。
しかしそこには多くの違いがあり、私から見ればDDDとBDDは同じものがほとんど何もなく、比較してはいけないものです。その違いは開発チームや全体としてのプロジェクトに関するものではなく、これから見ていくように、むしろ言語に関するものなのです。
今日の午後、私はScott Bellware氏に対して、BDDについて抱いていた関心についてメールを書きました。その作業の後で（ついでに、二人とも議論しながら飲むものを買いに出かけたのですが。彼が買ったのはパンプキンエールで、私が買ったのはコロナビールでした）私にとってはしばらくなかった、最も知的で面白い議論をしたのでした。
私はScottにBDDに関する次の問題意識を投げかけました。
BDDはよくTDD + DDDだと説明されるけれど、BDDで作られたものを見ても、ユビキタス・ランゲージ（"Ubiquitous Language"）の一部だと僕が考えるようなものはそこになく、もっとナイーブなレベルの何かがあるんだよ（これはEvansが明らかな名詞を見つける時に説明するものに似ています。下記参照）。BDDはどうやって、
１）僕らがDDDでやっているような深いモデルを見つけるんだ？
２）ユビキタス・ランゲージと共に先に進むんだ？成果物はモデルと歩調を合わせるために多大なリファクタリングを要求されるし、DDDでも言われている通り、「ドキュメントはコードと話し言葉に敬意を表さなければならない」ものだ。だから、進行形のユビキタス・ランゲージに合わせて、成果物を更新するのは必須のことなんだよ。
ここで明らかな名詞についてEvans氏に言及していますが、これは特にDDDの30ページに関連したものです。
話し言葉がその他のコミュニケーションの形態と乖離してしまうと、特に多くが失われてしまいます。私たち人間は話し言葉に関する天賦の才能を持っているからです。不幸なことに人が話をする時には、ドメインモデルの言語を使わないことが多いのです。
最初はこれが本当だとは思えないでしょうし、実際に例外もあるのですが、次に要件定義や設計の議論に参加する時には、どうか丁寧に耳を傾けて下さい。そこで耳にするのは、ビジネスの業界用語や素人による言い換えによる機能の説明であり、技術的な成果物や具体的な機能についての話でしょう。確かに、ドメインモデルに端を発した用語も出るでしょう。ビジネスの業界用語に由来する共通の言語に出てくる明らかな名詞は、典型的にオブジェクトとしてコーディングされますし、そういった用語は言及されることが多いです。しかし、現在のドメインモデルにおける関係や相互作用という観点から少しでも説明できるようなフレーズを耳にするでしょうか？
この点について明確にしておきます。
BDDから出て来るストーリーを見ると、ステークホルダーがモデルを記述しているのが見て取れますが、これはステークホルダーと開発者がユビキタス・ランゲージを定義するために作業するというDDDにおけるものとは違います。Dan North氏の「ストーリーについて」から規範的な具体例をとりあげます。
ストーリー：口座所持者が現金を引き出す。
As a：口座所持者の立場で
I want：ATMから現金を引き出したい
So that：銀行が閉まっている時でも現金が得られるように
シナリオ１：口座に十分な残高がある
Given：口座残高が$100で
And：カードが有効であり
And：機械に十分な現金が入っていれば
When：口座所持者が$20要求した場合に
Then：ATMは$20を支払い
And：口座残高は$80になり
And：カードは返却されなければならない。
シナリオ２：口座に十分な残高がない
Given：口座残高が$10で
And：カードが有効であり
And：機械に十分な現金が入っていれば
When：口座所持者が$20要求した場合に
Then：ATMは一切現金を支払わず
And：ATMは残高が足りないと言い
And：口座残高は$20のまま
And：カードは返却されなければならない。
シナリオ３：カードが無効化されている
Given：カードが無効化されていて
When：口座所持者が$20を要求した場合に
Then：ATMはカードを保管し
And：ATMはカードを保管したと言わなければならない。
ここにはEvans氏が論じているまさにそのものが見てとれます。このストーリーが語っているのは、事前条件と事後条件であり、DDDを押し進めた際に私たちのユビキタス・ランゲージになるであろうものとは、おそらく同じではありません。明らかな名詞は記述されていますが、そこからモデリングしなければいけないものはほとんどありません（ここから疑問が生じます）。これがユビキタス・ランゲージになるためには、多くの変更が必要になるでしょう。
上のテキストを見る限り、これは本当のドメインモデル開発ではありません。モデルをファサードという眼鏡を通じて見ているのです（BDDはファサード境界を記述するのには非常に優れているようです）。ここで成果物へと形式化されているのは、単にモデルのファサードを記録しただけのものです。しかし、そのモデルこそ、私たちが後の開発でユビキタス・ランゲージへと変えていこうと意図しているものなのです。
これを受けてScottがくれたのは非常に単純な答えでした。
ステークホルダーがドメインモデルについて気にする（もしくは気にしなければならない）と考える必要はないと思うよ。これは彼らが問題をとらえる見方なんだよ。（引用に誤りがあったら、それはコロナビールのせいです。）
これを聞いた瞬間、「冒涜だ」と思いました。と同時にDDDの禁止事項を投げかける準備ができました。DDDの「１つのチームに１つの言語」という視点から見たのと同じように、BDDがこれまで既に何度も見られた罠にはまっているのが分かるでしょう。Evans氏の言葉を引用します。
技術側の人々はしばしばビジネスエキスパートをドメインモデルから「守る」必要があると感じます。彼らはこう言うのです。
「ビジネスエキスパートには抽象的すぎる。」
「彼らにオブジェクトは理解できない。」
「彼らの用語で要件を集めなければならない。」これらは、チーム内で２つの言語を持つことの理由として聞かされたことのごく一部にすぎません。こういうことは忘れましょう。
もちろん、ドメインエキスパートとは関係のない設計を行うような技術的なコンポーネントもあるでしょう。しかし、モデルのコアはドメインエキスパートの興味をひくべきものです。あまりに抽象的？それでは抽象化が妥当であるとどうやって知ればいいのでしょうか？あなた方はドメインエキスパートと同じくらい深くドメインについて理解しているでしょうか？時として仕様的な要件はより実地的なレベルのユーザから集められ、そういうユーザのためにより具体的な用語が必要になるかもしれません。しかし、ドメインエキスパートは、自身のフィールドに関して何らか深く考えることができると思われます。洗練されたドメインエキスパートがモデルを理解しない場合、モデルに何か間違ったところがあるのです。
悲しいかな、Scottが言うようなステークホルダには、私も会ったことがあります。実際に思い返してみると、そのようなステークホルダの多くはDDDが勧められない種類のドメインに属していました。最近、Eric Evans氏もこのような議論をしています。
私がますます意識するようになっているものに、次のことがあります。それは、モデルの熱狂的支持者が最初から犯している基本的な誤りの１つが、全てをモデリングしなければならない、であるとか、全システムがモデリングされ、オブジェクト指向的に作られなければならないといった考え方であるということです。私が認識し始めたのは、そういうことによって、私たちがモデリングという投資から最大の効果を得ることができていない場所に向けた努力が薄められてしまうということであり、また、実際ほとんどのシステムは恐らく90%がCRUD（登録、参照、更新、削除）で、そういう問題に対してはよりシンプルな解決法があるということなのです。
BDDはDDDではないし、近いものでもありません。この位強調すれば十分でしょうか？BDDが焦点を当てているのは、DDDが必要とされない場所です。言い換えると、
BDDとDDDの関係はアクティブレコードとドメインモデルの関係のようなものです。
偉大な努力が払われていますが、BDDはユビキタス・ランゲージを含んでいません。BDDが含んでいるのは【共通言語】（"SHARED LANGUAGE"）です。BDDの成果物をユビキタス・ランゲージとの整合性を保つためにリファクタリングすることは、おそらくやる価値がありません。多くのステークホルダは統一された巨大な言語について議論することに興味はなく、求めているのは自分たちのモデルに対する認識が実装されることなのです。多くの場合、こういったものはシンプルなシステムで、きわめて直線的なプロセスで開発されます。そのようなステークホルダはAccountやTransferメソッド、あるいはAccountTransferServiceがあっても拍手をすることはありません。彼らにとってこれらは細かいことであり、BDDが形式化しようとしているのはこのような世界なのです。
BDDが焦点を当てるのは、開発チームとステークホルダの間の【共通言語】です。これはDDDのユビキタス・ランゲージと似ているかもしれませんが、明らかに同じものではありません。開発者は複雑性をステークホルダからファサードの背後に意図的に隠蔽しているのです。アーキテクチャ的にも言語的にもそうです。その代償として、ステークホルダは【受入仕様】（"ACCEPTANCE SPECIFICATION"）を【共通言語】を提供するのであり、開発者はシステムの内部的抽象化を行う際の基礎としてそれを使うことができるのです。
私がBDDの【共通言語】に同意するかどうかという問題についてですが、Scottとの議論において私が直面したのは他の問題と同じく「状況による」というものでした。個人的には本当のユビキタス・ランゲージから得ることができる利益について知っています。しかし同時に、そういった努力に対して興味のないステークホルダと仕事をしたこともあります。外側からの視点から、見たいようにモデルを見ている限り、そういうステークホルダは私がAccountクラスをどのようにモデリングしているかということについて気にしませんでした。彼らが求めているのは、プロジェクトが受入レベルを満たして完了することであり、それも総所有コスト（"TCO"）を低く抑えて保守が可能な形で、できる限り速くリリースすることなのです。
良し悪しは別として、ドメインエキスパートが実際はエキスパートではないこともあります :)
こうして問題の根本にたどり着きました。それは彼らの総所有コストをユビキタス・ランゲージで実現するのか、共通言語で実現するのかということです。思うに、共通言語よりもユビキタス・ランゲージの方が利益を享受できる程度は、システム内に含まれる単純なロジックの量と比較した時の複雑なロジックの量と比例するのです（統一モデルが必要な場合ですが）。長い目で見れば、BDDの勝率は7割を越えると思います。これが実際にシンプルな場合の割合だからです（もっと悪いケースもありますが）。
私は個人的にはDDDの側に立ち続けるでしょう。しかし、一般的には、BDDにはユビキタス・ランゲージが一切ないことを記しておくのが重要です。これは、ユビキタス・ランゲージを保つことがきわめて困難で、コストがかかるものだからです。もしユビキタス・ランゲージを探すのであれば、DDDを再読して下さい。【共通言語】の替わりに、DDDにおけるコンテキスト・マッピングとして見ることもできます。
補注：DDDとしては、境界上にいるステークホルダとのコンテキスト・マッピングの問題として私がとらえようとしていた時に、Scottがもう１つきわめて興味深いことを言っていました。それはここで触れる価値があります。
これは、異なった見方をするという問題ではなく、詳細度の異なる水準で見るという問題だよ。
象の話の用語を使えばこういうことです。象を扱う時には、目の見えない人がやるべきだったような大きな絵を見るだけではなく、象を見るネズミの視点、象の背に座るノミの視点、象の中に住むサナダムシの視点を認識することも同じく重要なのです！
BGM: The Ring of Fire, Johnny Cash "I fell into a burning ring of fire. Went down,down,down and the flames went higher. And it burns, burns, burns the ring of fire; the ring of fire"
訳注：この記事には多くのコメントが寄せられており、またYoung氏も、そのコメントに応える形で後日別の記事を書いています。内容に興味ないし異論を持たれた方は、それらのリソースもご参照ください。
