この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "ドメイン固有言語"
ドメイン固有言語（ドメインこゆうげんご）またはドメイン特化言語（ドメインとっかげんご、英語: domain-specific language、DSL）は、特定のタスク向けに設計されたコンピュータ言語[1]である。
DSL は一種類のタスクをうまく記述することに集中したプログラミング言語であり、古くから存在した。何らかのプログラミング言語それ自体の構文と処理系を利用する internal DSL（あるいは embedded DSL）と、独立した構文と処理系を持つ external DSL に大別されるが、そのいずれにしても近年の、自由度と機能が高いプログラミング言語により手軽に扱えるようになったことから広まっている。ドメイン固有モデリングの支持者によれば、ドメイン固有モデリングの発達と共にDSLという用語も広く知られるようになってきた、とされる。実際にはドメイン固有言語はモデリングとは特別な関係が何もあるわけでもなく（ドメイン固有モデリングのためのドメイン固有言語、といったものはあるが）、モデリング以外にもあらゆる分野のための言語がある。
例えば、ハードウェア記述言語のVerilog HDLやVHDL、データベースへの問い合わせ言語（SQLなど）、文脈自由文法を記述するBNFや正規文法を記述する正規表現、図を作成する言語を構築する Generic Eclipse Modeling System（英語版）、音響や音楽の合成用のCsound、グラフ（ネットワーク）描画システムGraphvizのDOT言語、ファイルの最終変更時刻と依存関係記述にもとづいたタスクランナーであるmakeなどがある。 DSL は、ある特定の領域（ドメイン）の問題を解決するために作られ、それ以外の領域の問題を解くことは想定していない。そもそも、言語とは何かを記述するためのものであって、何かを記述することで問題が解決する場合もあれば、余計に解決しなくなる場合もある。一方、汎用のプログラミング言語は一般に計算可能なものを計算するプログラムを、難しくなく書けることを意図して設計されている。 APIを公開しているDSLは、他のプログラミング言語から呼び出してライブラリのように使うことができる。 機能を拡張され続けた結果チューリング完全になってしまうDSLもある。つまり計算理論的には汎用のプログラミング言語と同等になってしまったということであるが、珍しいことではない[2]。そのようなDSLでもたいていは、設計目的外の用途のためのコードは可読性が乏しく、同じ目的を実現するにも手間がかかり、実用的ではない。 DSL は言語として（あるいは文法や構文として）非常に限定された目的で設計/実装される。DSL は視覚化された言語（ドメイン特化ダイアグラムとも言われる）の場合もあるし（GEMS
概要
設計と実装
例えば、grepというコマンドラインで使われるユーティリティはテキストとのパターンマッチを行うための正規表現が可能である。sedユーティリティは同様に正規表現を使ってテキストとパターンマッチングさせて、文字列の置換も行う。これらのツールはシェルスクリプトで利用され、より複雑なタスクを実行する一部を構成する（この段落の話題は、カーニハンらの書籍のタイトルでもあるSoftware Toolsと呼ばれる「道具」的なプログラム類において、ドメイン固有言語的なものがよく使われている、という話であって、DSLに重点がある話では本来はない）。
DSL には成熟したプログラミング言語なら当然持っているべきファイルシステムへのアクセス機能やプロセス間制御といった機能が欠けていることが多い。
多くのDSLはバイトコードや実行コードと言ったものにコンパイルされることはなく、他の様々な媒体向けのデータが生成されたり、システムに作用したりする（例えば、データベースにクエリを行う）。例えばGraphvizはPostScript[3]、GIF、JPEGなどを出力し、Csoundは音声ファイルを出力し、POVのようなレイトレーシング用言語はグラフィックスのファイルを出力する。SQLは関係モデルに基づいて設計されている関係データベースのへのクエリ（アクセス）言語である。
しかし別の多くのDSLは処理性能などのために、（場合によっては何らかのプログラミング言語への変換を経由して）バイトコードや実行コードと言ったものにコンパイルされ、そのコンパイルされたコードが他の様々な媒体向けのデータを生成したり、システムに作用したりする。とくに、プログラミング言語に埋め込むEDSLは埋め込み先のプログラミング言語に変換されるので、DSLがプログラミング言語でないという認識は必ずしも適切とはいえない。
プログラミングツール「プログラミングツール」を参照
一部のDSLは徐々に機能が追加されて完全なプログラミングツールとなってきているため、ある言語がDSLかそうでないかという判断はさらに複雑化している。好例として関数型言語とみなされているXSLTがある。XSLTはXMLのドキュメントツリーを変換するために設計された。しかし最初から、条件分岐と、引数のあるテンプレートの再帰適用により関数型のプログラミングが可能であった。さらにその後の機能追加でファイルシステム操作、文字列操作、その他のデータ型や操作などの機能が追加されたため、さらに一般的なプログラミングが可能なものになっている。また、PHPは、最初の時点ではWebページ作成に使うツールを集めたフレームワークであり、作者としても「スクリプト言語を作るなどといった考えはまったくなかった」（出典からの引用です）のであるが、その後に拡張が進み[4]、PHP 5ではオブジェクト指向や例外処理を備えた本格的な言語へと発展している。プログラミングに関することでは、モデル駆動工学では、OCL、QVT などの各種DSLが使われる。ただし、UMLは DSL ではなく汎用モデリング言語に分類されるのが一般的である。UML の「汎用」というのは、モデリングの対象を選ばない、という意味であり、プログラミング言語のことを汎用というのは全く文脈が違うわけで、モデリング言語というDSLであるはずだが「DSLではなく『汎用モデリング言語』に分類されるのが一般的」なのだそうである。
簡易言語はナイフのようなもので、様々な用途がある。DSLは電動ドリルのようなもので、穴を空けることにかけては強力なツールである。このメタファでは、それら工具に対し、汎用のプログラミング言語は工具の材料である工具鋼に相当する。道具というのは「一つの目的に特化する」のが基本であり、たとえばモンキーレンチや、さらには十徳ナイフのようなものは便利だが代用品である（プログラミング言語が十徳ナイフに相当するものではないのは言うまでもない）。 DSL を利用するパターンには以下のような場合がある:[5][6] DSLを採用するDSL には汎用プログラミング言語にはない次のような重要な設計目標がある:
DSLに関する話題
利用パターン
単独でDSLを利用する場合。また、（コマンドラインやMakefileから）ユーザー操作の直接的結果として呼び出される場合（Graphvizなど）。
プログラミング言語のマクロシステムを利用して実装されたDSLは、コンパイル時か読み込み時に汎用プログラミング言語に展開/変換される。メタプログラミングにより、汎用プログラム言語としてそのまま実行可能なDSLを構築することもできる。
C言語やPerlなどの汎用プログラミング言語で書かれたプログラムから（実行時に）呼び出され、特定の機能を実行して、その結果を主プログラミング言語に返して処理を続けるという形態で使われる DSL もある。
ユーザーアプリケーションにDSLが組み込まれている場合、そのアプリケーションのユーザーが書いたDSLコードを実行するか、アプリケーション自体がDSLコードを動的に生成して実行する。
設計目標