ドメイン固有言語ガイド

2000年代後半、私はRubyコミュニティの取り組み、fluent interfacesを作成したいという願望、そして言語ワークベンチの魅力的で漠然とした見込みによって刺激されたDSLの復活に深い関心を持つようになりました。DSLのアイデアを使用しているプロジェクトをいくつか見ましたが、ほとんどの人は、DSLを適切に構築および使用するためのオプションを十分に理解していませんでした。そこで、私は単純な内部および外部のテキストDSLで使用するパターンに関する書籍を執筆することで、この問題に取り組むことにしました。それ以来、この関心は薄れてきましたが、この本はこれらの手法をうまく捉えていると感じています。特に、ルールエンジン、デシジョンテーブル、ステートマシンなど、代替の計算モデルを捉えるための適応モデルの使用に焦点を当てています。

技術者以外の人向けにDSLの議論をまとめるように頼まれました。おそらくStephen O'Gradyを読みすぎたのかもしれませんが、どうしてもQ&A形式でやりたいという衝動に駆られました。というわけで、ここに掲載します。

ドメイン固有言語の話題が出ると、よくある疑問の1つは、正確に何がDSLであり、何がDSLでないかということです。問題は、DSLの正確な定義がなく、DSLと他のものとの間に大きなグレーゾーンがあることです。

ソフトウェア開発におけるほとんどの新しいアイデアは、実際には古いアイデアの新しいバリエーションです。この記事では、私が言語ワークベンチと呼ぶツールクラスの成長しているアイデア、たとえばIntentional Software、JetBrainsのメタプログラミングシステム、MicrosoftのSoftware Factoriesについて説明します。これらのツールは、私が言語指向プログラミングと呼ぶ古いスタイルの開発を取り入れ、言語指向プログラミングを有効なアプローチにするためにIDEツールを使用します。彼らが野望を達成できるかどうかを予言するほどではありませんが、これらのツールはソフトウェア開発の地平線上で最も興味深いもののいくつかであると思います。少なくとも概要として、それらがどのように機能し、将来の有用性に関する主な問題を説明するために、このエッセイを執筆するのに十分なほど興味深いものです。

私たちのソフトウェアロジックのほとんどはプログラミング言語で書かれており、これらはそのようなロジックを記述および進化させるための最良の環境を提供します。しかし、そのロジックを、命令型コードが解釈できるデータ構造（私が適応モデルと呼ぶもの）に移行することが便利な状況があります。ここでは、JavaScriptでの製品選択ロジックを示し、JSONでエンコードされた単純な本番ルールシステムにリファクタリングする方法を示します。このJSONデータを使用すると、異なるプログラミング言語を使用するデバイス間でこの選択ロジックを共有し、これらのデバイスのコードを更新せずにこのロジックを更新できます。

DSLを使用すると、ビジネス担当者はプログラマーを介さずにソフトウェアルールを記述できるようになりますか？

DSLについて話すとき、ビジネス担当者が自分でコードを書くという問題がよく提起されます。私はこの考え方にCOBOLの推論を適用するのが好きです。つまり、COBOLの当初の目的の1つは、プログラマーなしでソフトウェアを記述できるようにすることでしたが、それがどのように機能したかをご存知でしょう。したがって、プログラマーなしでコードを記述する計画が立てられるときはいつでも、COBOL（および他の多くのもの）が失敗したところで成功する特別な理由を尋ねなければなりません。

ドメイン固有言語（または実際には任意のコンピュータ言語）について話すときに、よく使われるフレーズは、構文ノイズです。RubyはJavaよりもノイズが少ない、または外部DSLは内部DSLよりもノイズが少ないと言うかもしれません。構文ノイズとは、人々が本当に言いたいことの一部ではなく、言語定義を満たすために存在している余分な文字のことです。ノイズ文字は、プログラムの意味を曖昧にし、プログラムが何をしているのかを解明しなければならなくなるため、良くありません。

私のドメイン固有言語に関する書籍では、私がDSLを説明するために使用する概念を整理するためにパターン構造を使用しています。このカタログは、その書籍のパターンのリストです。それぞれが各パターンのページにリンクされています。ページには詳細があまり含まれていませんが、各パターンの参照URIを提供します。