アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。
ただ、この回答については少し疑問が残っていて、実際は「確立された概念体系」と「ドメインの本質を表す概念群」との境界はそんなにはっきりしたものではないのではないかと思っている。例えば、8章「ブレークスルー」などで登場するシェアパイ（SharePie）は、代数的構造の1つである「群」の概念に沿ったもので、確立された概念体系、もしくはそれに限りなく近いものだが、DDD書籍ではドメインエキスパートがこの概念を操り、ユビキタス言語の一部にもなっている。このように、純粋にメカニズム的な意味を持った概念体系は確かにモデルの本質を表しはしないのであろうが、確立された概念体系自体がドメインの本質を表す場合もあるのではないかと思う。
ビジネス的な有用性はどこにあるのか
Evans氏発言要旨経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか？という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。
雑感
この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待していたものの、Evans氏は主にPartⅣの戦略的設計（Strategic Design）の有用性について語ったために、ギャップが生じたためだと思う。
DDDは一読するとオブジェクト指向分析・設計方法論に関する本のようにも見えるが、実際はOOに直接結びついているわけではない。ドメインを中心に設計をする上で都合の良いパラダイムが現状ではオブジェクトパラダイムであるために、実現方法を記した部分（PartⅡ、PartⅢ）がオブジェクト指向設計に沿った形で書かれているにすぎない。DDDにとって根本的に重要なのはOOではなく、その名が示すとおり「ドメイン」へのフォーカスだ。この点を踏まえたなら、コアドメインへの注力はシステム/ソフトウェア全体をドメインの観点から区分するという意味で、まさに大きな意思決定を行うレベルでのドメイン駆動設計そのものだということが理解できると思う。
OO話がなかったのは…残念でした。
OO話がなかったのは…残念でした。
ドメインエキスパートをどうやって巻き込むのか
Evans氏発言要旨
ドメインエキスパートとの最初のミーティングで、「あなたが最も難しく、面倒だと感じるのはどういった部分なのか？」「安眠を妨げるような問題はないか？」とたずねて、具体的なシナリオをあげてもらう。細かい問題は後で決めれば良い。画面項目の最大長や色などを聞くのはナンセンスで、ただでさえ忙しいドメインエキスパートの貴重な時間を浪費することになる。そんなことをしてはいけない。本当に難しい、重要な問題にフォーカスしてシナリオを描き、シナリオを解決できるモデルをホワイトボードに描き出して共有する。
仮にドメインエキスパートが示す問題がドメインにとってはさほど重要な問題ではなく、彼にとって重要・面倒であるだけであっても大きな問題ではない。彼と信頼関係を構築するのが重要。このセッションがうまくいけば、ドメインエキスパートはセッションを楽しみに待ってくれるようになることもある。これは実際にEvans氏が経験した話。
雑感
画面項目の最大長…といったくだりは刺さった。多くのプロジェクトでは、まさにこうしてドメインエキスパートの時間を無駄にしている。ここでも、ドメインにフォーカスし、重要な部分にリソースを投入する、というドメイン駆動の原則が生きている。リソースというのは、開発者のリソースだけではなく、ドメインエキスパートのリソースも同じなのだ。モデリングセッションの進め方はWhirlpoolに沿ったものだが、ここに至って、繰り返し型・反復型開発の重要性も浮き彫りになってくる。ウォーターフォール型の開発プロセスで、横並びに設計を進めるのなら、こうしたアプローチを取るのは難しくなるだろう。しかし、重要な部分を先に進めることを合意できているなら（RUPくらいなら顧客合意も難しくないだろう）、ドメインエキスパートにとって重要な問題にフォーカスすることで注意を引きつけ、それを知的に解決するさまを共有することでモデリングセッションを軌道にのせる姿も現実的なものとして見えてくるのではないだろうか。
一般的・形式的な概念体系をどう扱うか
問題要旨
書籍Domain Specific Languageでは、ドメインエキスパートとのコミュニケーションを促進するためにDSLを構築し、DSLの背後にある概念体型としてセマンティックモデル（Semantic Model）を導入する。このセマンティックモデルの一形態として代替計算モデル（Alternative Computational Model）が挙げられており、よりうまく問題領域にフィットする場合に有効である旨が記述されている。代替計算モデルとして挙げられているステートマシン（State Machine）、依存ネットワーク（Dependency Network）、決定表（Decision Table）などは言わば確立された形式的な概念体系であるのだが、こうした体系とDDDのモデルはどういった関係にあるのか。
Evans氏発言要旨
確立された概念体系自体は非常に有用であるものの、これは汎用的なものであって、ドメインの重要な概念を直接的に表すものではない。重要なのはむしろ、モデルからこうした概念体系を分離した後に残るものであり、それこそがドメインの概念をより良く表すものとなり得る。
雑感
これは、15章「蒸留（Distillation）」に属するパターンの1つである、凝集されたメカニズム（Cohesive Mechanisms）を念頭に置いた回答ではないかと思う。DDDの書籍では、組織内の関係を表すモデルからグラフ構造をCohesive Mechanismsとして取り出す例があげられており、こうすることで組織のモデルからグラフ構造にまつわる概念群（ノード、アークなど）を消し去って、残されたモデルをより本質的なものにしている。また、貨物輸送の例でも配送ルートを決定する際にグラフ構造が使われており、Itineraryを実装した際に混入したであろうグラフにまつわる概念群を引き剥がすことに成功している。これはDDD Sampleでも確認できる。
DSLの代替計算モデル相当をDDDに組み込む場合、最も素直なアプローチはCohesive Mechanismsとして利用することだと考えている。貨物輸送の例であれば、うまくすればエンドユーザーが書いたDSLスクリプトを解釈実行することで、直接配送ルートを表すグラフ構造を構築でき、このモデルを使って最適経路を計算できるだろう。
ただ、この回答については少し疑問が残っていて、実際は「確立された概念体系」と「ドメインの本質を表す概念群」との境界はそんなにはっきりしたものではないのではないかと思っている。例えば、8章「ブレークスルー」などで登場するシェアパイ（SharePie）は、代数的構造の1つである「群」の概念に沿ったもので、確立された概念体系、もしくはそれに限りなく近いものだが、DDD書籍ではドメインエキスパートがこの概念を操り、ユビキタス言語の一部にもなっている。このように、純粋にメカニズム的な意味を持った概念体系は確かにモデルの本質を表しはしないのであろうが、確立された概念体系自体がドメインの本質を表す場合もあるのではないかと思う。
# この話、酔っ払った状態でEvans氏に話そうとしたけどstuckしてしまった…無念すぎる。酔っ払ってなくてもダメだったかもしれないことは置いておこう…。
問題要旨
英語以外の言語を用いる場合、ほとんどの実装言語が英語に沿ったものであるため、ドメイン概念をそのままソフトウェアとして実装できないことが問題になる。仮にここで、実装言語にあわせて英語を混在させた場合、ユビキタス言語が歪められてしまう。
Evans氏発言要旨
ソースコードでも日本語を使え。以上。
雑感
実際にはこれほど乱暴な話になったわけではない。Evans氏も英語以外の言語での実践経験はなく、他の言語圏でどうやって対処しているのかは不思議に思っていた様子。ただ、Javaのコードを見ながら話をした際にクラス名に対して日本語でコメントがつけられているのを見て、これではダメだと感じたようだった。「ドメインエキスパートがこの言葉（日本語コメントで書かれたクラス名）を使っているのなら、なぜクラス名にこれを使わない？」とのこと。「日本語でJava等を書くと、Java慣習にかたっぱしから違反してしまうので問題なんだ、コードも読みづらいし」と反論（？）してみたものの、「重要なのはドメインの概念であって、技術的な問題はそれに比べれば瑣末なものだろう？」と言われてしまい、もう納得するしかなかった。実際のところ、主語・動詞・目的語・修飾語等の位置が異なるため、英語に比べるとかなり違和感のあるコードが出来上がってしまうのだが、DDDがこれまで述べてきた「ドメイン重視、技術要素は二の次」という姿勢が貫かれていることを知ってすっきりした。これでDDDerは、日本語でコードを書いてみなくちゃならなくなった！実践した人は、Evans氏にフィードバックしてあげましょう。
コメント