実践プログラミングDSL読了：ドメインモデルとDSLについて思ったことをまとめてみる

実践プログラミングDSL ドメイン特化言語の設計と実装のノウハウ (Programmer’s SELECTION)

相変わらず読むのが遅いので、有用な書評はだいたい出そろっている頃だと思います。 id:kmizushima さんに教えていただいて読んだ本です。私の周りではあんまり大きくバズる感じがしていないのが若干寂しいところなのですが、良い本なので思ったことをまとめてみたいと思います。

まず基本的に、この本は写経のための本であると思っています。Scala,Ruby,Clojure,Groovyなどの言語を利用してDSLを構築するためのノウハウや実コード例が非常に豊富です。用途を固定したプログラミング手法の実践方法なので、常に役に立つわけではないと思いますが*1、それぞれの言語でのテクニックで参考になる部分があるかと思います。(私の場合、パーサコンビネータやモナドに対して、今までもやっとしていたところが少しすっきりしました)ですが、前半の(人によっては退屈な)DSLが必要とされる背景などで、ドメインモデルに対する認識やモデルの作成からDSL構築までの流れを知っておくと、何の為にテクニックを駆使してDSLを構築するのか、という目的が明確になり、より本書に対する理解が深まると感じました。
よって、今回はドメインモデルからDSLまでの流れについて本書を読んで思ったことをまとめてみることにします*2。以下、断定的に書いていますが私の理解の範疇での話であり、突っ込みは大歓迎です。

ドメインって何だっけ？

簡単に言うと「お客さんの業務」です。お客さんには業務上解決したい問題があります。この解決したい問題全体が、問題ドメインです。われわれ開発者にはまずお客さんからの視点として提示されます。

上図のもやもやっとしている部分がドメインです。お客さんがもやもやっとした部分の内側にいることに注意して下さい。システム開発において、たいていの場合はお客さんは対象ドメインを理解しています*3。それに対して我々開発者は、最初ドメインの外側にいます。これはどんなに似た業務についてのシステム構築経験があっても同じです。
システム開発の専門家である我々開発者は、このような曖昧な状況からスタートしてドメインについて理解し、お客さんと一緒にシステムが価値を提供するためのドメインの写像を構築する必要があります。

最初は「もの」から認識される

まず大切なことは、お客さんとの対話を繰り返すことです。そして、開発者が対話を進めるためにまずは「もの」からアプローチします。お客さんとの対話の中で出てくる単語に注目して、それが示す役割などを掘り下げていくのです。すると次第に「もの＝オブジェクト」が共有されるようになります。

さらに対話を進めていくと、「もの」同士の関連が少しずつ見えてきます。

ここで共有された「もの」と関連がドメインモデルであり、システムで解決する対象です。我々開発者の専門性は、このモデルに対する提案や分析手法などの形で発揮されます。重要なことは、「もの」とその関連を図や言葉などの手段(モデル)で表現し、それをお客さんと開発者で同じものとして共有することです。

モデルが共有できないとどうなるか

今、プライベートでお手伝いをさせていただいているプロジェクトがこのあたりの段階なのですが、「もの」の認識と共有がままならないので、どうしてもお互いが話す言葉がぶれてしまいます。例えば、一つのことを話すのに何度も例えを使いながら話をしたり、同じ単語を話していても文脈のずれが発生したりなどの現象が出ます。
このような状況で開発を進めてしまうと、発生することは皆さんよくご存知だと思います。そうあれです、あれ。同じモデルを共有していないために人によって様々な解釈が成り立ち、そのギャップが不幸な形で現れた結果です。「設計工程」や「要件定義」を形だけ済ませて膨大なドキュメントを作っても、デスマったりユーザの満足度が低くなる要因がここにあります。モデルはドキュメントの体裁ではありません。
おそらく本書の前提は、モデルの共有ができていることであるはずです。なぜなら、本書にモデルケースで概念の不一致に悩んでいる形跡はありません*4。

モデル(図)だけだとこぼしてしまう

ここで、図としてのモデルの表現力が静的な側面で主に発揮されることに注目しましょう。対話を通じて得たモデルは図だけでは表現しきれない部分があり、図で表せない動的な部分は言葉で示されています。この言葉にもドメインに取っては重要な示唆が含まれています。
これらはユビキタス言語の一部としても表現されるはずですが、どうせならこのような共通の語彙も何らかの形で表現できたらシステム開発におけるあらゆる不幸の原因となるギャップをなくしていく足がかりになると思いませんか？

そこでDSLの登場です

開発者は問題のドメインモデルを技術的な解決ドメインに対応づけて実装していきます。このときに共通の語彙で解決ドメインの実装を表現するための手法がDSLです。DSLは解決ドメインの技術的な層に対して、お客さんや開発者のための共通の語彙を元にしたAPIを提供する層となります。実装上にDSLを構築することで、問題ドメインとのトレースがしやすくなり、お客さんにとっても開発者にとっても理解しやすい実装になるはずです。
やっと本書の大前提までたどり着きました。ふう。ここまでが本書の第１章から第２章に相当する内容です。

ここまで押さえれば、後は本書にあげられたサンプルを写経するのみです。おそらく単なるプログラミングテクニックとは別のものが見えてくるのではないでしょうか。

まとめ

長々と書いてきましたが、まとめると以下の５点です。

• DSLのベースになるのは「ユビキタス言語」
• ドメインモデルがある程度固らないとDSLの構築自体がままならない
• 静的なモデルではあらわせない部分をDSLで表現
• 感触としてはリポジトリオブジェクトやファクトリオブジェクト内で使われそう
• 相変わらずイテレーティブなプロセスが重要

というわけで、本書単体でも十分読み応え、写経し応えがありますが、その背景(前提)にあるドメインモデルへの理解のためにDDD(ドメイン駆動設計)を併読することを強くお勧めします。できればドメイン知識の説明は文章だけではなく、クラス図あたりがあるともっと理解が深まったかもしれません。まあ、必要なドメイン知識は文章として記載されていますし、DSLとして表されているのでそこからモデルを作ってみても良いかもしれません。

先日、私が勤めている会社に羽生田栄一さんが基調講演をしに来てくれたのですが、羽生田さんは「DSLを簡単に書ける言語」としてScalaを推しているとのことでした。本書の書評をされているブログで、「Scalaすげーが言いたい本」と書いてある方がいましたが、あたらずしも遠からずかなあ、と思います。本書のテーマは「DSLをいかに書くか」であり、DSLを構築する際の表現力に富む言語をサンプルとして主軸に据えるのは当然のことだからです。Scalaらしさが出ていて良いじゃないですか、と思うのは私だけですかね？

今回のエントリ、まだまだ詰めて考えたいところがかなりあります。というわけで、冬の合同勉強会にもう少しDDDよりの話として再構築していきたいと思っています。

おまけ：ところでここは日本です

本書で表現されているDSLは全て英語です。が、お客さんは日本人であることがほとんどです。となるとDSLも日本語で表現されるべき？と思ってしまいますね。この辺りって深く議論されているのでしょうか。
ちなみに私は、こういう議論をするとTTSneoとかひまわりとか思い出してしまう世代です。

*1:個人的な意見ですが、不要な場面で無理にDSLを使うのはコードの可読性を下げてしまうと思います。

*2:つまり本書の内容にはほとんど入り込まないのですが、そこは気にしないように。

*3:スタートアップをのぞく

*4:モデルケースだからという話もありますが、そもそも概念の不一致が重要でないからこそ切り捨てているわけです。