プリンターや通信機器など組込みシステムの ドライバーSW開発では、新規HWへの修正・変更が主な作業であり、DSMは適合させにくいのではという質問をよくいただきます。しかしながらデバイスドライバーの開発で多くの良い事例があります。

 
 1. 一般にドライバーSWは、DSMを適応させる良きドメインとなる。なぜなら HWの外観そのものが明確で具体的に問題空間を表現する。
 
2. DSMからコード生成させるためのフレームワーク、ドメインフレームワークは、ドライバーSW開発の場合既に存在し、活用されていることが多い。ソースコードがコールする多くの機能は、ベースライブラリとして管理されるローレベルのコードや、Cプリプロセッサマクロとして用意されているので。
 
エンタープライズや上位のアプリケーションなどではコードが肥大化し、各行は理解しやすくても、相当な行数となり、繰返される同等のグループ行をドメインスペシフィックフレームワークの関数としてリファクタリングすることが有効となる。
それに対してドライバーコードの各行はビット処理などローレベルで理解が難しいが、肥大化するような心配はない。そしてドライバーSWにDSMを適応する効果は、抽象モデルによりわかりやすくなり（結果エラーを削減）、生産性が向上すること。メタモデル内に定義するルールによって、更にエラーの要因を排除できる。
 
3. この場合でも生成されるコードに対して変更（差分開発）はしない。Cコンパイラで生成されるオブジェクトをモディファイしないのと同じで、モデルを変更する。モデルの変更では間に合わないケースでは、メタモデル（モデリング言語）やコードジェネレータを修正する。
例えば新しいHW向けの開発ではメタモデルとコードジェネレータを拡張する。その作業は、メタモデリング担当者（熟練者）のとって僅か（年間数日程度）で済む。
 
ドライバーコードも他のDSM事例同様のエレメントを持つ：
 
　- 異なる状態内の異なる振舞いに対する状態遷移
 
　- 複数階層（レイヤ）に及ぶ状態；例えばパワーセーブモードであっても無かってもHWからのメッセージを受信する場合。　パワーセーブモードのトップレベルグラフ、そして異なるサブグラフで振舞いを持つことは最適になり得る。大抵の場合、振舞いはどのモードでも同じ。そして、パワーセーブモードのコンディションに応じて１つのグラフを各振舞いに対して描くことは容易。”Power saving mode” は、モデリング言語のコンセプトとなる。
 
　- エラー、非常ボタン、リセットなどはトップレベルで扱える。もしそれらが如何なる場合も殆ど同じに動作し、追加のクリーンアップの振舞いがローレベルで必要な場合。ジェネレータはクリーンアップコードを自動生成できる。　例えば、現在の関数（機能）がローカル変数のためにメモリをアロケートしていている場合、処理から抜ける前にそれを開放できる。
 
　- 変数のように動作する IOアドレス；値が読書きされるような。　IOポートへの値の変更なども、ステートダイアグラム（状態遷移図）内のイベントとしてモデル化できる（HWに依存）
 
DSM構築の手順は、ドライバーSWでも他と同じで以下の通り。
 
a) いつもの共通事象・部分を識別
b) ドライバーの実装ごとで異なる部分を識別
c) 共通事象・部分を部品化
d) 異なる部分を指定するDSM言語を構築する
e) 部品を統合してコードを生成できるコードジェネレータを実装する
 
SW（あるいはドライバーSW）が個々に独立して（再利用無く）開発されている場合、共通部品を見出すことが一番の課題となる。
 
通信インフラのプラットフォームの事例
 
油圧クレーンの事例
 
モータ制御の事例