DDDの読書記録（第2章、コミュニケーションと言語の使い方）
アジャイルプロセスのXPでもコミュニケーションに重点が置かれますが、その考え方に影響を受けているDDDでも業務担当者とプログラマーとの間のコミュニケーションを重視しているようです。しかし、これは「報連相」「根回し」「場の空気を読む」といった、いわゆる業界の新人研修やOJTで先輩社員から叩き込まれるような人間的なコミュニケーションのことよりは、むしろ、共通の言語やモデルによる科学的なコミュニケーションという点に重点を置いています。もちろん、最終的にコミュニケーションは人間同士で行うものなので、ヒューマンスキルが重要なのは言うまでもないことですが、日本の場合伝統的にチームの和を乱さないとか事なかれ主義のようなところもあり、事実に基づく正直なコミュニケーションが良くないとされるケースが多いようです。つまり、エンジニアとしてよりもむしろ、サラリーマンとしてのコミュニケーション能力が重視されるということでしょうか。（この点については以前に以下で書いた内容とも関連しています。プログラマーの本来のコミュニケーション能力とは - 達人プログラマーを目指して）
とにかく、本章では、チーム全体が単一のドメインモデルを構築することの重要性とその手段としてのユビキタス言語について説明されています。
ユビキタス言語（UBIQUITOUS LANGUAGE、P24）
ドメインエキスパートは、ソフトウェア開発における技術的な専門用語のことは部分的にしか理解せず、代わりに自分の得意分野の専門用語を使用する。それも、さまざまなニュアンスで使うだろう。
これは第1章の例でもそうですし、実際、業務アプリケーションの設計を担当したことのある人であれば、一般的な業務の用語を理解するのがいかに困難であるか、身にしみて経験している人が多いのではないでしょうか。金融などの専門知識が必要で業務上の概念そのものが難しいといったことはもちろんですが、同じ会社でもシステムやサブシステムによって言葉の使われ方が微妙にずれていたりすることは普通にあります。一方、開発者は開発者の側で技術的な専門用語を用いて設計や実装の方式を考えています。このような状態がチーム内で業務担当者とプログラマー間での円滑なコミュニケーションを阻害する要因となります。それゆえ、
モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコード*1において、その言語を厳密に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。
・・・
ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害するあいまいさや不整合に目を光らせるべきである。
というユビキタス言語パターンの解決策が提示されます。
例2.1貨物輸送プログラムを完成させる*2
この例ではまったく同じ機能に対して、最小限の抽象化しか行っていない手続き指向の設計を行った場合と、ユビキタス言語パターンを採用してオブジェクト指向のドメインモデルに基づく設計を行った場合に、ドメインエキスパートとプログラマーとの間の会話の内容がどのように変化するかといった実に興味深い例となっています。
なお、この例で貨物予約と翻訳されているのは原書ではcargo bookingとなっており、内容的には貨物の物流システムにおける集荷機能に関連して、最適な輸送経路を算出して登録するような機能についてドメインエキスパートである物流担当者とプログラマー（エヴァンス氏？）が話し合っている状況が描かれています。経路の算出は荷済み地点、荷下ろし地点を入力することで行いますが、省略可能（optとして示されている）なパラメーターとして通関地点の入力が可能な仕様になっています。つまり、われわれが日常よく利用するシステムで言えば電車の路線検索やカーナビの経路選択のようなものに近いと考えられます。少なくともここでは貨物予約という訳語にあまり惑わされないほうが理解しやすいでしょう。
ここで28ページのシナリオ1の会話と29ページのシナリオ2の会話の違いが理解できるでしょうか。もちろん、エヴァンスさん的には28ページの会話に対して29ページの会話の方がDDD的に見てイケテいるということですが、英語力の問題もありますが、私は最初に原書を読んだ時には実はよく理解できませんでした。
まず、理解すべき違いとして、シナリオ1の方はプログラマーが実装レベルのテーブル、行など技術的な用語を使って会話しているのに対して、シナリオ2ではドメインのユビキタス言語を使って会話をしているという点が大きく異なります。つまり、太字の部分がユビキタス言語としてドメインエキスパートとの間で共有できている言語なのですが、これが圧倒的に多くなっており、コミュニケーションのパイプが太くなっています。表面的にはこのユビキタス言語の分量の違いなのですが、その他気づく相違点として、
- シナリオ1では経路選択サービスがDBテーブルにデータを保存しているという実装の詳細が隠蔽されていない。
- シナリオ1ではサービスがDB登録という副作用つきで実現されているが、シナリオ2では純粋に副作用のない関数として実現されている。
- シナリオ2では経路仕様という重要概念がクラス（値オブジェクト）として明示的に抽出されている
- シナリオ2では（JPAのような）透過的永続性により永続層がドメイン層の設計から意図的に分離されている
などがあげられると思います。オブジェクト指向による抽象化に慣れていないと、シナリオ1の方が簡単と感じてしまうかもしれませんが、今後より複雑な業務機能を実現していく基礎とするためにはシナリオ2のような設計が望ましいのです。そうすることで、ドメインエキスパートとプログラマーがお互いに近い距離を保ちながらモデルを洗練させていくことが可能だからです。
ちなみに、28ページの6行目は
ユーザ：行を削除する？まあ、いいでしょう。あとは、それまでに通関地点を一切通過していなくても、通関地点が変更されたら経路計画は作り直す必要があります。
と訳されていますが、原文は
User:Delete the rows? OK, whatever. Anyway, if we didn't have a customs clearance point at all before, we'll have to do the same thing.
と書かれていますので、「それまでに通関地点を一切通過していなくても」の部分は誤訳ではないかと考えられます。
ユーザ：行を削除する？まあ、いいでしょう。とにかく、それまでに通関地点が入力されていない場合でも、通関地点が変更されたら同様に経路計画は作り直す必要があります。
くらいでよいのではと思います。とにかく、この例のドメインエキスパートはデータベースの知識があまり無いようです。その点において、会話のぎこちなさを感じ取ることができればよいのではないかと思います。
声に出してモデリングする（P30）
ドメインモデルで使われるユビキタス言語は単にプログラムやUMLのモデルに書かれるだけでなく、会話の中で使われることでより効果が発揮されるという主張です。ユビキタス言語パターンでは補足として、
システムについて語る際には、モデルをいろいろと試してみること。モデルの要素と相互作用を使い、モデルに許された方法で概念を結びつけながら、シナリオを声に出して描写すること。表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること。
と書かれています。この点については確かに非常に重要なのですが、日本人の場合、コードを日本語で記述することは稀な一方で、会話を英語で行うということもまた稀なため口頭の言語とコードの記述言語に大きな隔たりがあるという点は、どうしても無視することができない問題であると思います。特に機械翻訳してみればわかるように単純な単語のマッピングでは英語と日本語の翻訳は行えないのであり、実際大きな隔たりがあります。もちろん特別なチームであれば公用語を英語にしてすべて英語ベースで考えるといったことも可能なのかもしれませんが、現実問題としては厳しいところがありますね。
ところで、エヴァンスさんは先日QConでお会いした際にはJavaのクラス名やメソッド名を日本語にしたらどうかとおっしゃっていました。ただし、
- Javaを含めてほとんどのOO言語の場合、予約語やクラスライブラリーが英語
- メソッド呼び出しなどの語順が日本語として不自然*3
- 日本語は膠着語で英語の単語のような自然な区切りが無い*4
- 日本語には大文字、小文字といったアルファベットの概念がない
など大きな違いがあり、単純にはいきません。現状はユビキタス言語としては日本語を使い、Java Docなどで補足するなどが現実的なところでしょうか。
１つのチームに１つの言語（P32）
従来のオブジェクト指向開発の常識では、「分析モデル」「設計モデル」「実装モデル」などのように、詳細度に応じて異なるモデルを作るということが常識でした。しかし、DDDでは同一コンテキストにおいて複数のモデルが存在することを認めていません。誤解してはいけないのは、アプリケーションやシステムごとの、それぞれのコンテキストにおいては別々のモデルが存在してもかまわないという点です。あくまでも一つの開発チームというコンテキストにおいて、単一のモデルをドメインエキスパートも開発者も共有するべきということを主張しています。そのための手段としてユビキタス言語を設定することが重要なわけです。
DDDの重要な仮説として、オブジェクト指向のモデルがドメインエキスパートにも技術者にも理解できるはずであるということがある点に注意してください。日本の業界だとドメインエキスパートの側はもちろんのこと、技術者の側ですらオブジェクト指向を毛嫌いし、真剣に取り入れようとしない傾向があるというのが現実です。その結果、人海戦術的な忍耐力勝負の間違った方向性の努力のみが評価される傾向があります。*5とにかく、DDD以前の前提として、SI業界のオブジェクト指向開発に対するアレルギーの問題を解決することが先決であると思います。
ドキュメントと図（P34）
私は、ソフトウェア設計について議論する会議に出席する時はいつでも、ホワイトボードやスケッチブックに図を描かないと、ほとんど頭を動かすことができない。大部分はUML図で、たいていはクラス図かオブジェクト相互作用図である。
と書かれているように、エヴァンス氏はビジュアル脳の人のようです。図に対する重点の置き方はやはり個人差のあるところであり、テキスト文書の方が理解しやすい人もいるとは思いますが、一般的に図を描くことによってモデルに対する理解が深まることは確かでしょう。
しかし、注意しなくてはいけないのは、そのようにUML図が好きなエヴァンス氏ですら、図はあくまでも補助、設計の主体はコードにあると考えている点ですね。
これらの図はモデルを簡略化し、説明するためのものであり、要点を明確にする時には、標準でない表記法も多少取り入れている。設計上の制約を示してはいるが、あらゆる詳細についての設計仕様書ではない。図が表現しているのは考え方の骨格なのだ。
設計に関する本質的な詳細はコードにおいてとらえられる。適切に作成された実装は透過的で、根底にあるモデルを明らかにしなければならない。
図と同様のことは設計書についても言えます。設計書はコードを説明する補助に過ぎないとする考え方ですね。とにかく、多くの現場ではUML図やExcel方眼紙などの上流のエンジニアが作った成果物をありがたがる一方で、下流のプログラマーの書いたコードの品質は尊重されません。上流、下流という階級差別社会を想起させる言葉の響きも絶対に悪い影響を与えていると思いますが、下流行程の成果物であるプログラムコードの品質など、全体から見ればたいして影響がないと信じられています。アジャイルの発想ではむしろ逆なのであり、コードこそが品質を左右する上で最重要の主体であり、図や文書は説明用の補助手段と考えるべきです。DDDを組織に取り入れるためには、まず、このパラダイムシフトが絶対に必要不可欠です。DDDにおける実装コードの重要性については第3章で説明されています。
ちなみに、このDDDのパラダイムで考えてしまうため、私はSIerのエンジニアが好きなExcel表からコードを自動生成するといったようなEDD（Excel-Driven Design）的な発想が好きになれないのだと思います。日本のSI業界の現場で根強く浸透しているEDDはDDDの対極にある考え方だと思うのです。*6
説明のためのモデル（P39）
DDDでは一つのチームは一つのドメインモデルを共有すべきと主張していますが、ドメインについて学ぶ手段として補助的に利用するのであれば、別の説明用のモデルが存在してもよいとしています。そして、そうした説明用のモデルはUMLを使ったオブジェクトモデルある必要もなく、目的に応じてさまざまな手法を使えばよいと書かれています。
*1:日本語の問題をどのように解決すべきか検討する必要があります。多くの場合、カタカナ言葉をユビキタス言語として使うことになるのではないかと思います。あるいは、日本語を正式とし、Java Docなどで対応付けを行うなどが考えられるでしょうか。
*2:ちなみに、このセクションの原書のタイトルは「Working out a cargo router」で、より直訳的に正確に訳すと「貨物輸送経路の算出機能に取り組む」くらいの意味になるのではないかと思います。
*3:多くの日本人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか？ - 達人プログラマーを目指して
*4:本来の日本語には空白文字という概念がない。全角空白などは本来書式のための概念ですし。
*5:SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して、日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
