DSLs を読書開始

Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))

を購入。 chapter1を読んだ。

前半は、状態遷移を、いかにテキスト形式で簡潔にわかりやすく表現するかを例に DSLが何なのかを説明している。
Chapter1のつかみは、いい感じ。

状態遷移の ドメインモデルで言葉と関係で構造を説明したのち

テキスト形式で状態遷移を記述

• ベタにJavaで状態遷移をCode に書いた例
• XMLで状態遷移を宣言的に構造化した例
• 独自言語で XMLのノイズを 取り除いた例
• 言語内DSL Ruby版で、（独自言語に比べればノイズがあるが、）十分に簡潔に記述した例
• 言語内DSL Java版で、記述する例(メソッドチェーンを使った、fluent interface)

後半は、テキストのDSL ではない workbench, Code generation． テキストDSLのVisualizationの話に入っていく。

ファウラーらしい文体．メリット、デメリットを淡々と提示している節々に至言が。

ここからは、Chapter 1 を読んで、想起した事をメモ。

アクティビティ図も状態遷移の変種。過去のお仕事で、アクティビティ図からXMLを経由してJavaを生成するといったことをやっていたんだが、いろいろ思い出させる内容。
ワークフロー定義をテキスト表記ではどうしてもわかりにくいところが出てくる。
なんだが、ツールからgenerationした Code がダーティだといろいろ困る。
構成管理ツールをの利用を考えると、ワークフロー定義は, バイナリーファイルではなくて、テキストファイルでcommitした方が，いろいろ便利。テキストのDSLファイルをビジュアルツールが読み込んで参照 and 編集。編集した内容を保存すると Code Generationでテキスト DSLができるがいいんだろうな。うまく使えれば、ワークフロー定義のDiffが読める。マージできる。

最近の私のお仕事だと、Accounting Patternsを中核においたモデルを使いやすくするための API設計をやっていたが、イマドキだと、そうじゃなくてコアモデル(semantic model)を使いやすくするための DSL設計に頭をまわすべきなんだろうなぁ。

Accounting Patternsのコアのモデルのクラス図は何となくわかりにくいんだが、
TE登録は、テキスト構造で簡潔に記述できそうな気は、過去の素振りでなんとなくつかんでいる。

transaction do
  from do
    account "田中"
    entry 99.yen
  end           
  to do
    account "鈴木"
    entry 90.yen
  end           
  to do
    account "佐藤"
    entry 9.yen
  end
end
# 制約 
#     transation内の from(+) と to(-) の entryの合計は０
# 事前条件
#    account "田中", "鈴木", "佐藤"がいる
# 事後条件
#     transactionが追加されている
#     田中:accountに -99:entryが追加されている
#     鈴木:accountに 90:entryが追加されている
#     佐藤:accountに 9:entryが追加されている

あるいは

transaction do
  from "田中", 99.yen
  to "鈴木", 90.yen 
  to "佐藤", 9.yen
# 制約 transation内の from(+) と to(-) の entryの合計は０
end

このテキスト記述レベルなら、顧客とのコミュニケーションに使用できるだろうか。
ドメイン構造(振る舞い？？)を簡潔に表現できて会話できるような気もしなくないが。はてさて。

その他に、直接関わっていなかったが、YAMLファイルで定義した内容を視覚化するツールを見た。
Visualizationの例なんだろう。