2011年4月20日水曜日

QCon Tokyo 2011 アーキテクチャパネルディスカッション+DDD雑多ネタ

アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。

ビジネス的な有用性はどこにあるのか
Evans氏発言要旨
経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか?という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。

雑感
この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待していたものの、Evans氏は主にPartⅣの戦略的設計(Strategic Design)の有用性について語ったために、ギャップが生じたためだと思う。
DDDは一読するとオブジェクト指向分析・設計方法論に関する本のようにも見えるが、実際はOOに直接結びついているわけではない。ドメインを中心に設計をする上で都合の良いパラダイムが現状ではオブジェクトパラダイムであるために、実現方法を記した部分(PartⅡ、PartⅢ)がオブジェクト指向設計に沿った形で書かれているにすぎない。DDDにとって根本的に重要なのは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氏にフィードバックしてあげましょう。


2011年4月18日月曜日

QCon Tokyo 2011

QCon Tokyo 2011に、DDD読書会(JavaEE勉強会)のコミュニティ枠として参加させていただきました。初回開催となる2009以来2年ぶりの参加になります。

今回のセッションプログラムはビアパーティまであわせると総数が21で、以下の6つに分類されています。総プログラム数からすると多彩な内容ですね。
  • クラウド
  • Design & Patterns
  • 技術
  • クオリティ & テスト
  • アーキテクチャ
  • ケーススタディ
しかし、なんといっても今回の目玉は、DDDの創始者Eric Evans氏の来日でしょう。基調講演に通常プログラム、パネルディスカッションと盛りだくさんの内容でした。僕はこのDDDと、クラウド関連のセッションに的を絞って出席してきました。具体的には、以下の7つ+ビアパーティに参加、という形です。
  • ドメイン駆動設計:複雑な問題群に対する有用なモデルたち
  • Webアプリケーションエンジニアが見てきたこの10年
  • クラウドのデータアーキテクチャー設計の原則
  • Understanding IA: The Extension of Man 2011
  • クラウドコンピューティングの未来:10年後の情報システムを考える
  • ドメイン駆動設計においてレガシーシステムを扱うための戦略
  • アーキテクチャパネルディスカッション

セッションの感想
QCon2009風に感想を分類すると、こんな感じでした。

[面白かった!]
  • クラウドのデータアーキテクチャー設計の原則
  • クラウドコンピューティングの未来:10年後の情報システムを考える
  • ドメイン駆動設計においてレガシーシステムを扱うための戦略
  • アーキテクチャパネルディスカッション
[ふつう]
  • ドメイン駆動設計:複雑な問題群に対する有用なモデルたち

[いまいち]
  • Webアプリケーションエンジニアが見てきたこの10年
  • Understanding IA: The Extension of Man 2011

雑感
今回のQConでは、2年前に比べると統一的な方向性のようなものを見出すことはできませんでした。色々な人が色々なことをやっていて、その成果を個々に見ているような感じです。これは、僕が主に出席したクラウド系のセッションとDDD関係のセッションの方向性がかなり異なっているのが大きな理由かもしれません。

クラウド系
クラウド系で特に面白かったのは、佐藤一郎氏の「クラウドコンピューティングの未来:10年後の情報システムを考える」でした。この講演では、クラウドコンピューティングをソフトウェア技術中心の他のセッションとは異なった視点から捉えており、クラウドコンピューティングと物流業態との類似性や他の業態を模した異なる形態でのクラウドコンピューティングの可能性、アプリケーションとの関係、アプリケーションのビジネス化のヒントが散りばめられていて、非常に新鮮なものでした。

DDD系
DDDのセッションで面白かったのは、Eric Evans氏の「アーキテクチャパネルディスカッション」でした。ここでの収穫はなんといっても、Evans氏自らドメインエキスパートとのモデリングセッションについて、具体例を交えて生き生きと語ってくれたことでした。ドメインエキスパートとのモデリングセッション自体はDDD書籍にもいくつか例示されているのですが、どのようにしてドメインエキスパートとのモデリングに入っていくのか、的を絞ったモデリングセッションを続けるにはどうすればいいのか、どの程度の頻度でモデリングを行うのか、など実際に実行する上で不明な部分が多く、果たして現実的に可能なのだろうか、と疑問に思った人は多数いたように思います。今回は氏自らセッションへの入り方、雰囲気作り、関係の保ち方、焦点の絞り方といった部分を語ってくれたことで、こうした部分を現実感を持って理解することができました。こうした方法は、Model Exploration Whirlpoolというミニプロセスとして形式的にまとめられており、DDDの前進を感じることができました。

# 面白かったものについては、備忘録的に個別にエントリを書こうかと思います。

2011年4月14日木曜日

ブレイクスルー体験記@DevLove Beautiful Development

DevLoveさんのイベント「DevLove Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう」にて発表させていただきました。
僕のITスキルが低い&緊張のために、画面が小さいことに気づかずにそのまま進めてしまいました。見えにくかった方、申し訳ありませんでしたorz
イベント全体の情報は、オフィシャルサイトにて非常にわかりやすく整理されています。ぜひそちらへ。
実は、スライドの最後には僕の大好きな漫画である日本橋ヨヲコ先生の「G戦場ヘヴンズドア」の1シーンを入れてました。すさまじい才能を持ちながら、漫画編集者の父との確執からストーリーが作れなくなった鉄男と、漫画家の父との確執から歪んだ形で小説家を目指す町蔵が心を通わせ、ともに戦場に歩み出そうとするシーンです。

町蔵「バカかお前…何こんな中途半端なモン世に出そうとしてんだよ!!オレは本気が見てえんだよ!!人の顔色うかがって描いてんじゃねえよ!!」
鉄男「作れないんだ、ストーリーが。もう言いたいことがないんだ、オレは、からっぽだから堺田君にひかれたんだよ。」
町蔵(……ああ、こいつもか。)
町蔵(誰にも、)
町蔵(期待してないんだな。)
町蔵「お前は天才かもしれねえ。けどそれだけだ。才能だとか画力だとか、プロはもうそんなとこで生きてねえ。」
町蔵「万人受け狙えば通用するような甘い世界でもねえ。」
町蔵「いいか、オレと組むなら手加減すんな。」
町蔵「…もしお前がもう一度…」
町蔵「オレを震えさせてくれるなら、」
町蔵「この世界で、一緒に汚れてやる。」

ヘタレだから出せなかったよ。でももう何も言うことはないよ。

2011年4月13日水曜日

Code Generation & Language Workbenches@DSL読書会

少し前になりますが、DSL読書会@JavaEE勉強会でCode GenerationとLanguage Workbenchesのまとめを発表したので、ここにも載せておきます。



Google Docsで作ってみたのですが、Slide Shareと勝手が違っていて、埋め込んだ状態でうまく閲覧できそうにないです。まともに見たい人は、最大化ボタンをクリックするのが良いかと思います。

僕の担当分はDSL本の最後の部分で、この資料はそれまでの部分のまとめが他の人から発表されている前提で作っています。これだけ見てもあまりわからないかもしれませんので、字だけになりますが少しだけ補足しておきます(Fowler DSLのエッセンスにさらっと目を通しておかれると、少しは分かり良いかもしれません)。

DSL Overview
DSL概念全体の中でCode Generationがどのような位置づけにあるかを俯瞰するために、Fowler DSLの全体像を示しています。

DSLスクリプトを言語処理層(Language Processing Layer、パーサー/ビルダーなど)が処理することでセマンティックモデルが構築され、セマンティックモデルをアプリケーションから直接実行したり、他の環境向けにコードを生成してから実行することで望みの計算を行います。セマンティックモデルはFowler DSLのキーとなるもので、Fowler DSLを他のDSLアプローチと隔てている最も大きな要因の一つです。

DSLは、DSLスクリプトと言語処理層の形態によって内部DSLと外部DSLに分類されます。内部DSLはDSLスクリプト、言語処理層、セマンティックモデルを同じプログラミング言語上に構築するもので、外部DSLはDSLスクリプトを独立した言語で記述するものです。
言語処理層を構成するパターン群を総称して、構文解析戦略(Syntactic Analysis Strategy)と呼び、特に内部DSLを構築するテクニックが豊富に語られています。

セマンティックモデルから望みの結果を得るためのパターン群を総称して、出力生成戦略(Output Production Strategy)と呼びます。Code Generationはこのうちの1部分という位置づけです。

ちなみに、ハートマークはFowler自身がセマンティックモデルを直接実行するスタイルを好んでいる印としてつけています。本命はセマンティックモデルの直接実行であり、コードジェネレーションは仕方なくやっている、という匂いが文章の端々から感じられるためです。

Code Generation Patterns (What to produce)
コード生成のためのパターンのうち、「何を(どのようなスタイルのコードを)生成するか」についてのパターンを示したスライドです。

Model Ignorant Generationは、その名の通りモデルらしきものがまったく存在しないコードを生成するパターンです。モデルが持つ振る舞いはすべて、コードの中に手続きの形で平坦化されて埋めこまれます。これは、ターゲット環境がサポートする言語に抽象化能力が乏しく、モデルが構成できない場合や、モデルを実体化できるほどメモリリソースに余裕がない場合にある意味仕方なく取られるパターンです。もちろんFowlerはあまり好んではいません。

Model Aware Generationは、ターゲット環境上にも(限られた形態かもしれないものの)モデルを構築し、モデルを操作する形のコードを生成するパターンです。Fowlerお気にです。

Code Generation Patterns (How to produce)
続いて、「どうコードを生成するか」についてのパターンを示したスライドです。「どう作るか」は「何を作るか」に強く依存することに注意が必要です。

Templated Generationは、テンプレートエンジンを使ってコード出力するパターンです。生成対象となるコードで静的に決定される部分が多い場合に有効です。Model Ignorant Generationを使う場合、平坦化されたコードが一定のパターンで繰り返されることが多いため、このパターンが向いています。通常テンプレートエンジンは複雑な制御機構を持っていないため、分岐や選択が入り組んだ複雑な生成には向きません。

Transformer Generationは、モデルを変換するコードをカスタムで作るパターンであり、要はTemplated Generation以外の場合を指しています。複雑な制御が必要であったり、コードに動的に決定される部分が多い場合に向いています。Model Aware Generationを使う場合、コードの記述は最小限となり、繰り返しも少なく静的に決定される部分も小さいため、このアプローチが向いています。

Language Workbenches
言語ワークベンチは、「独自のカスタムDSLを容易に構築できるようにしてくれる環境」です。さらに次のスライドで、言語ワークベンチに共通する要素を紹介しています。FowlerのDSL概念と似た形はとっていますが、異なる部分もいくつかあります。

最も大きな違いは、セマンティックモデルが振る舞いを持つことはほとんどなく、必要な振る舞いはコードジェネレーションのプロセスでテンプレートエンジンによって埋め込まれる点です。
セマンティックモデルが振る舞いを持たないのは、言語ワークベンチが汎用的・統一的に個々のセマンティックモデルを扱えるようにするために「メタモデル」を用意した(せざるを得なかった)のが主な原因のようです。あまり詳しくはないのですが、メタモデルに汎用的な振る舞いの表現を埋め込むのは確かに難しそうです。

もう一つは、セマンティックモデルを様々な方法で視覚化したり、編集したりできる編集環境が用意されている点です。自分が見たツールでは、メタモデルと関連づけながら独自エディタを生成するための開発環境が用意されていました。

MOFとの関係
最後のMOFとの関連はおまけみたいなもんです。とりあえずMOFは忘れてよし!

手抜きで字だらけなのであまり分かりやすくはないと思いますが…