DDDオフィシャルサイトに掲載されている、DSM(Domain Specific Modeling)に関するインタビューを起こしてみた。オリジナルのビデオはここ。どうでもいいと思ったところや一部よくわからなかったところは飛ばしてるし、間違っているところもあると思います ^^;
はじめに
Interviewer(以下"I"):
Peter Bellが来てくれた。自己紹介してくれる？
Peter Bell(以下"P"):
カンファレンスなど、色んな場面でこのトピックについて話している。DSMやコードジェネレーションについて話すのにベストな人間だと思う。
DSMとは
I: 今日はDSMについて話したいが、まずはDSMが何か教えてもらえるだろうか？
P: 役に立つ良い定義としては「開発プロセスのスピードアップ、アプリケーションの一部または全体の生成、コードベースのメンテナンスなどのためにDSLを使うこと」のように言えると思う。
I: じゃあ、DSLって何？
P: 3つのコンポーネントがあると思っている。
まず1つは、Javaなどの汎用言語とは異なり、特定の問題を解決するためのものであるということ。
2つ目は、コンストラクションのレベルをひきあげるものであること。JavaやC#とおなじようにかかなくても良い。
3つ目は、実行可能であるということ。ユビキタス言語は必ずしも実行可能でなくてもいいが、DSLはジェネレーションやインタープリタを通して実行できる。
I: それがユビキタス言語とDSLの違いなんだね？
P: その通り。DSMはアプリケーションを生成したり実行したりするのに十分なユースケースのセットにフォーカスしていて、ユビキタス言語から直接アプリケーションを生成する。こうすることで色々メリットがある。
I: プロジェクトでは、会話で使われるようなユビキタス言語もあればコードにあらわれるユビキタス言語もある。後者は実行可能なユビキタス言語、つまりDSLなのか？
P: そう言える。えーとここで、DSMの世界で重要なDSLの興味深い区別について話しておきたい。内部DSLと外部DSLだ。内部DSLはAPIとかRuby Groovyのような言語を使って、人間が読めるようなDSLをコード内に作るアプローチだ。このアプローチではDSLの利点をフルに受けることはできない。なぜなら、ホスト言語の構文上の問題を気にしなければならないからだ。
外部DSLはよりパワフルで、DSLをコードの外部に持ち出し、DSLのステートメントを書くためのツールを別途用意できる。これは、箱と線で書けるようにもできるし、テキストで書くようにもできるし、スプレッドシートで書くようにもできる。
外部DSLの利点はジェネレートされた個々のステートメントをテストしなくていいので開発やメンテナンスのスピードをあげることができること。
I: 利点についての話があったが、他に利点はある？
P: 最も大きなものとしては、テスティングコストの低下があげられる。よくできたユビキタス言語は確かに、ステークホルダーとプログラマの間のコミュニケーションの問題を改善できる。しかし、コードへの変換時にはインピーダンスミスマッチがあるため、ここで理解の齟齬が発生し、バグの発生につながってしまう。DSMではこのような事態を完全に避けられる。ステークホルダーとコミュニケートし、彼らが話すことをそのまま書き、コードをジェネレートできる。
I: 言語が正しければ、テストの必要はない？
P: セマンティクスはもちろんテストする。DSLのステートメントが正しくその意図を表しているか、つまり与えられたステートメントが正しくジェネレートされるか、もしくは正しくインタープリタで実行されるかどうかはテストするということだ。しかし、すべての個々のステートメントをテストする必要はない。
I: 開発のスピードがあがるとのことだが、アップグレードも頻繁になるのでは？
P: その通り。頻繁にビルドするようにもなる。だが、メンテナンスの際に細かなコードブロックを見るのではなく、意図が明示されたDSL（ユビキタス言語）を見ればいいからメンテナンスも楽になる。
I: 利点にはすべてトレードオフがある。モデルが変更された場合、言語も変更することになると思うが、既存のツールでこの変更に対応するのはどれくらい難しい？
P: シンプルなリファクタリングサポートは既に存在しており、軽微な変更には問題なく対応できるが、根本的な変更に対しては無力。ただし、これはJavaやらC#を使っていても同じ。
ドメイン（に関する理解）が安定するまで、ジェネレータやインタープリタの作成を先延ばしにするのも良いかもしれない。
DSMにまつわる誤解
I: 誤解について話したい。DSMについては色んな話（誤解？）を聞いたが、そのうちのいくつかはUMLについてだった。
P: そりゃDSMではもっとも有害な誤解だと思う。仮に私がDSMをMDAやUMLからはじめていたとしても、UMLは使い続けなかったと思う。UMLは世界中で多くの人が使っていて、標準化もされており、多くの利点がある。しかしUMLの問題は、記述のレベルは抽象的すぎるということ。ステレオタイプでドメインのコンセプトを表せるようになってはいるが、クラスやメソッドが何をすべきかは何も決められていない。クラスごとに箱が1つ用意されるだけだ。なので、モデルからモデルへの変換やモデルからのテキストへの変換は簡単ではない。XMIみたいに。MDAがDSMの小さなサブセットにすぎないことを理解しておくことは非常に重要だと思う。
MetaCaseとかOpenArchitectureWareはEclipseプラグインも提供していて、開発者はテキスト指向のDSLを書く事ができる。これは、MDAに比べるとだいぶ使いやすいと思う。
DSLとドメインエキスパート
I: DSLはドメインエキスパートが書けるようにするべき？
P: ここはDSMに関してさまざまな関心がある部分だ。秘書が会計システムを書けるようにしようとしている、とかね。DSMアプローチでドメインエキスパートがDSLを書けるようにすることはできる。が、より利点があるのはドメインエキスパートが読めるようなDSLを作る事。ドメインエキスパートとプログラマの間のミスコミュニケーションを防ぐ事ができる。ユビキタス言語が引き起こしがちな、実装時の齟齬を防ぐ事ができる。
I: 少し自分の経験について話させてもらうと、ユニットテストやシナリオテストを書いてドメインエキスパートと共有した時、ドメインエキスパートはJavaなどのシンタックスノイズに悩まされていた。ユビキタス言語を使っていたとしても、ドメインエキスパートには（コードが何を意味しているのか）説明しなくてはならない。DSLを使えばわかりやすくできるように思うが、どうか？
P: BDDのようなアプローチが既に存在しているよね。統合テストではあまりできていないが、DSLが貢献できるいい例だと思う。統合テストにDSLのアプローチを持ち込むことで、ドメインエキスパートにとってとても読みやすくなる。将来はもっとよくなって欲しい。
Big Design Upfront or Agile
I: ドメインを前もって知っていれば、急激な変更が少なくなり、DSLにとって利点が大きいとするなら、前もってヘビーな分析作業をしなくてはならないのでは？
P: Big Design Upfrontをやりたがる人は最近ではほとんどいないと思う。コミュニティは、よりアジャイルなアプローチを取ろうとしている。MetaEdit + MetaCaseなどが良い例だ。これは、頻繁なモデルの変更を助けるような機能が豊富に用意されている。DSMは決してBDUではないことを強調しておきたい。
どの程度コード生成すべきか
I: アプリケーション全体を生成すべきか？
P: コード生成については色んな考えがある。アプリケーション全体を生成しなければならない、というものもあれば、アプリケーション全体を生成なんてできっこない、というものもある。これは、どちらも間違っていると思う。
100%の自動生成は可能ではある。変数のないテンプレートのようなものを使えば、既存のコードに1対1対応するようなコード生成はできる。だが現実には、（このようなアプローチで）すべてのコードを生成するのは意味がない。
DSMの世界では、色んなコードジェネレーションのツールがあり、コードを書くのが非常につらい、クラスやAOP、イベントドリブンプログラミングなどを書かなくてすむようにしている。これらのツールではジェネレートされたコードとカスタムコードは分離して扱うことができ、これら両方でアプリケーション全体を構成することができる。100%のコードを自動生成する必要はない。ドメインモデルが比較的リッチな場所を探し、ドメインエキスパートとコミュニケートして、DSLを作る、といった作業にスタッフをあてるといいだろう。そういうエリアにDSMを適用するのは労力に見合った利点があるからだ。
DSMに適したプロジェクト
I: DSMはどんなプロジェクトに向いている？
P: 良い質問だ。プロジェクトをよりDSMに適したものにしてくれるいくつかの要素があると思う。
1つ目、これはあまり言ってないことだが、DSMの熟達度だ。SpringやAOPを導入する時と同じで、最初に技術を導入するときには色んな面倒なことがある。また、動的言語、パーシャルクラス、クロージャなどを使う事でエレガントなアプリケーションをすばやく作り上げる事ができるが、開発者がそれをメンテナンスできるとは限らない。
なので、DSMの経験がある人をプロジェクトにいれて、経験をプロジェクトに持ち込むことが重要だ。これは非常に助けになる。
他の話としては、能力が許す範囲でいくつものプロジェクトを並行にすすめられるしても、投資を回収するには、ドメインの特定のエリアにとどまり、DSMがより長い時間使われるようにしなければならないということだ。DSMにはかなりのオーバーヘッドがあるので、6回以上やりたいかもしれないが…外部DSL用のツールがこの種の問題を解決しようとしてはいる。
水平的ドメインと垂直的ドメイン
ドメインは水平的にも垂直的にもなり得ることを理解するのも重要だ。
垂直的なドメインでは、成果は（例えば）1つの保険会社のためだけに使われる。
だが一方で、Webの部分は何度も同じようなものを生成することになる。例えば、ドレスショップ向けのeコマースと法律事務所向けの文書リポジトリなど。これが水平的で技術的なドメイン。水平的な技術ドメインはどこでも変わらないので、我々はモデル、コントローラー、バリデーション、リレーションシップなどWebアプリケーションを迅速に構築するための一連のDSLを既にもっている。
1つの企業で働いている人…つまり垂直的ドメインを対象にしている人たちは、領域を限定することで、DSMの能力を最大限に生かし、素早くアプリケーションを作ったりメンテナンスしたりしている。多量のJavaのコードに戻ることなく、少ない文で正確に意図が表現されているからだ。
現実のDSL/DSLの構築方法
I: HibernateはDSL？
P: HibernateはORMに関するDSLをいくつか示している。
こういう言語を作る場合、どのように始めればいいか聞かれることがあるのだが、盗めばいい。
ORM, DI, AOPのような水平的ドメインを扱うなら、既に多数のDSLが存在するので、この上にかぶせる形でシンプルな、カスタマイズされた自分のユースケース向けの小さなサブセットを作れば良い。
水平的ドメイン（たぶん垂直的の間違い）では、XMLスキーマも良い出発点になるだろう。銀行や保険の業界では、標準がすでに存在している。それらのサブセットを作る形で、必要に応じて自分の状況に応じてカスタマイズすればいい。
ドメインのコアコンセプトを理解する方法
I: ある特定のドメインを扱うような場合、ドメインに関する市販本などもあるが、読んでる？ドメインのコアコンセプトをどうやって知っている？
P: DDDと連携していくのがいいと思っている。
DDDは（DSLにつながる）ユビキタス言語を作るためのアプローチをあげており、DSMはジェネレートやインタープリタを使って効率的に実行する方法を持っている。これら2つのコミュニティは、お互いにディスカッションするといいと思う。既に2つのコミュニティでは活発なコミュニケーションがあると思っているが、より強くしていきたい。DSMコミュニティはDDDコミュニティからよりよく言語を設計する方法を学べるし、DDDは言語を実行可能にする方法を学べる。
I: 今日はどうもありがとう。
雑感
一部マーケ的においはするものの、全体としてはまっとうなことを話している印象。コード生成に関するスタンスも現実的だとは思う。しかし、DSMという新たな用語は必要なんだろうか？世の中を混乱させたり、コミュニティの評判を下げかねないので"DSL"を使い続けた方が良いのではないかと感じた。
また、DDDが向かうべき方向として良いのかどうか、今ひとつ確信が持てない。実行可能なユビキタス言語を作ることで、色んなロスがなくなるというが、それが本当かどうかは具体例を見てみないとなんとも言えないな。ドメインエキスパートの可読性を保ったままDSLを構築できるのだろうか？ユビキタス言語全体がDSLとして構築されるとは思えないのでサブセットになるのだろうが、一部だけ妙に形式的になるのだろうか？モノが見てみたい。
はじめに
Interviewer(以下"I"):
Peter Bellが来てくれた。自己紹介してくれる？
Peter Bell(以下"P"):
カンファレンスなど、色んな場面でこのトピックについて話している。DSMやコードジェネレーションについて話すのにベストな人間だと思う。
DSMとは
I: 今日はDSMについて話したいが、まずはDSMが何か教えてもらえるだろうか？
P: 役に立つ良い定義としては「開発プロセスのスピードアップ、アプリケーションの一部または全体の生成、コードベースのメンテナンスなどのためにDSLを使うこと」のように言えると思う。
I: じゃあ、DSLって何？
P: 3つのコンポーネントがあると思っている。
まず1つは、Javaなどの汎用言語とは異なり、特定の問題を解決するためのものであるということ。
2つ目は、コンストラクションのレベルをひきあげるものであること。JavaやC#とおなじようにかかなくても良い。
3つ目は、実行可能であるということ。ユビキタス言語は必ずしも実行可能でなくてもいいが、DSLはジェネレーションやインタープリタを通して実行できる。
I: それがユビキタス言語とDSLの違いなんだね？
P: その通り。DSMはアプリケーションを生成したり実行したりするのに十分なユースケースのセットにフォーカスしていて、ユビキタス言語から直接アプリケーションを生成する。こうすることで色々メリットがある。
I: プロジェクトでは、会話で使われるようなユビキタス言語もあればコードにあらわれるユビキタス言語もある。後者は実行可能なユビキタス言語、つまりDSLなのか？
P: そう言える。えーとここで、DSMの世界で重要なDSLの興味深い区別について話しておきたい。内部DSLと外部DSLだ。内部DSLはAPIとかRuby Groovyのような言語を使って、人間が読めるようなDSLをコード内に作るアプローチだ。このアプローチではDSLの利点をフルに受けることはできない。なぜなら、ホスト言語の構文上の問題を気にしなければならないからだ。
外部DSLはよりパワフルで、DSLをコードの外部に持ち出し、DSLのステートメントを書くためのツールを別途用意できる。これは、箱と線で書けるようにもできるし、テキストで書くようにもできるし、スプレッドシートで書くようにもできる。
外部DSLの利点はジェネレートされた個々のステートメントをテストしなくていいので開発やメンテナンスのスピードをあげることができること。
I: 利点についての話があったが、他に利点はある？
P: 最も大きなものとしては、テスティングコストの低下があげられる。よくできたユビキタス言語は確かに、ステークホルダーとプログラマの間のコミュニケーションの問題を改善できる。しかし、コードへの変換時にはインピーダンスミスマッチがあるため、ここで理解の齟齬が発生し、バグの発生につながってしまう。DSMではこのような事態を完全に避けられる。ステークホルダーとコミュニケートし、彼らが話すことをそのまま書き、コードをジェネレートできる。
I: 言語が正しければ、テストの必要はない？
P: セマンティクスはもちろんテストする。DSLのステートメントが正しくその意図を表しているか、つまり与えられたステートメントが正しくジェネレートされるか、もしくは正しくインタープリタで実行されるかどうかはテストするということだ。しかし、すべての個々のステートメントをテストする必要はない。
I: 開発のスピードがあがるとのことだが、アップグレードも頻繁になるのでは？
P: その通り。頻繁にビルドするようにもなる。だが、メンテナンスの際に細かなコードブロックを見るのではなく、意図が明示されたDSL（ユビキタス言語）を見ればいいからメンテナンスも楽になる。
I: 利点にはすべてトレードオフがある。モデルが変更された場合、言語も変更することになると思うが、既存のツールでこの変更に対応するのはどれくらい難しい？
P: シンプルなリファクタリングサポートは既に存在しており、軽微な変更には問題なく対応できるが、根本的な変更に対しては無力。ただし、これはJavaやらC#を使っていても同じ。
ドメイン（に関する理解）が安定するまで、ジェネレータやインタープリタの作成を先延ばしにするのも良いかもしれない。
DSMにまつわる誤解
I: 誤解について話したい。DSMについては色んな話（誤解？）を聞いたが、そのうちのいくつかはUMLについてだった。
P: そりゃDSMではもっとも有害な誤解だと思う。仮に私がDSMをMDAやUMLからはじめていたとしても、UMLは使い続けなかったと思う。UMLは世界中で多くの人が使っていて、標準化もされており、多くの利点がある。しかしUMLの問題は、記述のレベルは抽象的すぎるということ。ステレオタイプでドメインのコンセプトを表せるようになってはいるが、クラスやメソッドが何をすべきかは何も決められていない。クラスごとに箱が1つ用意されるだけだ。なので、モデルからモデルへの変換やモデルからのテキストへの変換は簡単ではない。XMIみたいに。MDAがDSMの小さなサブセットにすぎないことを理解しておくことは非常に重要だと思う。
MetaCaseとかOpenArchitectureWareはEclipseプラグインも提供していて、開発者はテキスト指向のDSLを書く事ができる。これは、MDAに比べるとだいぶ使いやすいと思う。
DSLとドメインエキスパート
I: DSLはドメインエキスパートが書けるようにするべき？
P: ここはDSMに関してさまざまな関心がある部分だ。秘書が会計システムを書けるようにしようとしている、とかね。DSMアプローチでドメインエキスパートがDSLを書けるようにすることはできる。が、より利点があるのはドメインエキスパートが読めるようなDSLを作る事。ドメインエキスパートとプログラマの間のミスコミュニケーションを防ぐ事ができる。ユビキタス言語が引き起こしがちな、実装時の齟齬を防ぐ事ができる。
I: 少し自分の経験について話させてもらうと、ユニットテストやシナリオテストを書いてドメインエキスパートと共有した時、ドメインエキスパートはJavaなどのシンタックスノイズに悩まされていた。ユビキタス言語を使っていたとしても、ドメインエキスパートには（コードが何を意味しているのか）説明しなくてはならない。DSLを使えばわかりやすくできるように思うが、どうか？
P: BDDのようなアプローチが既に存在しているよね。統合テストではあまりできていないが、DSLが貢献できるいい例だと思う。統合テストにDSLのアプローチを持ち込むことで、ドメインエキスパートにとってとても読みやすくなる。将来はもっとよくなって欲しい。
Big Design Upfront or Agile
I: ドメインを前もって知っていれば、急激な変更が少なくなり、DSLにとって利点が大きいとするなら、前もってヘビーな分析作業をしなくてはならないのでは？
P: Big Design Upfrontをやりたがる人は最近ではほとんどいないと思う。コミュニティは、よりアジャイルなアプローチを取ろうとしている。MetaEdit + MetaCaseなどが良い例だ。これは、頻繁なモデルの変更を助けるような機能が豊富に用意されている。DSMは決してBDUではないことを強調しておきたい。
どの程度コード生成すべきか
I: アプリケーション全体を生成すべきか？
P: コード生成については色んな考えがある。アプリケーション全体を生成しなければならない、というものもあれば、アプリケーション全体を生成なんてできっこない、というものもある。これは、どちらも間違っていると思う。
100%の自動生成は可能ではある。変数のないテンプレートのようなものを使えば、既存のコードに1対1対応するようなコード生成はできる。だが現実には、（このようなアプローチで）すべてのコードを生成するのは意味がない。
DSMの世界では、色んなコードジェネレーションのツールがあり、コードを書くのが非常につらい、クラスやAOP、イベントドリブンプログラミングなどを書かなくてすむようにしている。これらのツールではジェネレートされたコードとカスタムコードは分離して扱うことができ、これら両方でアプリケーション全体を構成することができる。100%のコードを自動生成する必要はない。ドメインモデルが比較的リッチな場所を探し、ドメインエキスパートとコミュニケートして、DSLを作る、といった作業にスタッフをあてるといいだろう。そういうエリアにDSMを適用するのは労力に見合った利点があるからだ。
DSMに適したプロジェクト
I: DSMはどんなプロジェクトに向いている？
P: 良い質問だ。プロジェクトをよりDSMに適したものにしてくれるいくつかの要素があると思う。
1つ目、これはあまり言ってないことだが、DSMの熟達度だ。SpringやAOPを導入する時と同じで、最初に技術を導入するときには色んな面倒なことがある。また、動的言語、パーシャルクラス、クロージャなどを使う事でエレガントなアプリケーションをすばやく作り上げる事ができるが、開発者がそれをメンテナンスできるとは限らない。
なので、DSMの経験がある人をプロジェクトにいれて、経験をプロジェクトに持ち込むことが重要だ。これは非常に助けになる。
他の話としては、能力が許す範囲でいくつものプロジェクトを並行にすすめられるしても、投資を回収するには、ドメインの特定のエリアにとどまり、DSMがより長い時間使われるようにしなければならないということだ。DSMにはかなりのオーバーヘッドがあるので、6回以上やりたいかもしれないが…外部DSL用のツールがこの種の問題を解決しようとしてはいる。
水平的ドメインと垂直的ドメイン
ドメインは水平的にも垂直的にもなり得ることを理解するのも重要だ。
垂直的なドメインでは、成果は（例えば）1つの保険会社のためだけに使われる。
だが一方で、Webの部分は何度も同じようなものを生成することになる。例えば、ドレスショップ向けのeコマースと法律事務所向けの文書リポジトリなど。これが水平的で技術的なドメイン。水平的な技術ドメインはどこでも変わらないので、我々はモデル、コントローラー、バリデーション、リレーションシップなどWebアプリケーションを迅速に構築するための一連のDSLを既にもっている。
1つの企業で働いている人…つまり垂直的ドメインを対象にしている人たちは、領域を限定することで、DSMの能力を最大限に生かし、素早くアプリケーションを作ったりメンテナンスしたりしている。多量のJavaのコードに戻ることなく、少ない文で正確に意図が表現されているからだ。
現実のDSL/DSLの構築方法
I: HibernateはDSL？
P: HibernateはORMに関するDSLをいくつか示している。
こういう言語を作る場合、どのように始めればいいか聞かれることがあるのだが、盗めばいい。
ORM, DI, AOPのような水平的ドメインを扱うなら、既に多数のDSLが存在するので、この上にかぶせる形でシンプルな、カスタマイズされた自分のユースケース向けの小さなサブセットを作れば良い。
水平的ドメイン（たぶん垂直的の間違い）では、XMLスキーマも良い出発点になるだろう。銀行や保険の業界では、標準がすでに存在している。それらのサブセットを作る形で、必要に応じて自分の状況に応じてカスタマイズすればいい。
ドメインのコアコンセプトを理解する方法
I: ある特定のドメインを扱うような場合、ドメインに関する市販本などもあるが、読んでる？ドメインのコアコンセプトをどうやって知っている？
P: DDDと連携していくのがいいと思っている。
DDDは（DSLにつながる）ユビキタス言語を作るためのアプローチをあげており、DSMはジェネレートやインタープリタを使って効率的に実行する方法を持っている。これら2つのコミュニティは、お互いにディスカッションするといいと思う。既に2つのコミュニティでは活発なコミュニケーションがあると思っているが、より強くしていきたい。DSMコミュニティはDDDコミュニティからよりよく言語を設計する方法を学べるし、DDDは言語を実行可能にする方法を学べる。
I: 今日はどうもありがとう。
雑感
一部マーケ的においはするものの、全体としてはまっとうなことを話している印象。コード生成に関するスタンスも現実的だとは思う。しかし、DSMという新たな用語は必要なんだろうか？世の中を混乱させたり、コミュニティの評判を下げかねないので"DSL"を使い続けた方が良いのではないかと感じた。
また、DDDが向かうべき方向として良いのかどうか、今ひとつ確信が持てない。実行可能なユビキタス言語を作ることで、色んなロスがなくなるというが、それが本当かどうかは具体例を見てみないとなんとも言えないな。ドメインエキスパートの可読性を保ったままDSLを構築できるのだろうか？ユビキタス言語全体がDSLとして構築されるとは思えないのでサブセットになるのだろうが、一部だけ妙に形式的になるのだろうか？モノが見てみたい。
コメント