ブログ
ドメイン駆動設計（DDD）入門
目次
はじめに
IT業界で働いていると、「DDD」「ドメイン駆動設計」という言葉を目にする機会が何度かありました。
気になってはいたもののなかなか触れられずにいましたが、今回ようやく学び始めることができたので、その内容を共有したいと思います。
正式には「ドメイン駆動設計(Domain-Driven Design)」といいます。（※「開発」ではなく「設計」）
学んでいく中で、学生時代に論文を書いた経験と重なる部分があることに気づいたので、その発見も含めてまとめます。
「ドメイン」って何? – DNSのドメインじゃないの?
最初に疑問に思ったのが「ドメイン」という言葉の意味です。
私は最初、DNSの「example.com」のようなドメインを想像していました。（同じように思っている方がいてくれると嬉しいのですが）
しかし、DDDでいうドメインは意味が全く違いました。
ドメインとは、開発したソフトウェアが利用される業界や分野、事業、業務のことです。
具体的には、会計システムにおける「金銭」や「振込処理」、SNSにおける「投稿」や「ユーザー」などが該当します。
つまり、プログラムを適用する対象となる領域を指すのです。DNSドメインとは全く別物です。
ドメイン駆動設計(DDD)とは?
従来の開発との違い
従来の開発：
- データベース構造から設計を始める
- 技術的な都合を優先する
- 実装しやすい形に最適化する
DDD：
- ビジネスの本質を中心に据えた設計
- 業務仕様やビジネスルールを軸に設計を行う
- コードがビジネスロジックを忠実に表現する
業務の実現や顧客の課題解決が第一であり、最新の技術や開発手法の活用は必須とされません。
これがDDDの特徴です。
DDDの一連の流れ(フェーズ)
DDDは大きく2つのフェーズに分かれると感じました。
戦略的設計(Strategic Design)
ざっくり言うと、ビジネスの専門家との要件定義と共通言語の策定だと言えそうです。
- ドメインエキスパート（ビジネスの専門家）との対話
- ビジネスを動かす人（業務の専門家）から知識を引き出す
- ユビキタス言語の策定
- ビジネス側・開発側での共通言語を定義する
- 境界づけられたコンテキストの決定
- 同じ言葉が同じ意味を持つ範囲を明確にする
- ドメインモデリング
- ビジネスの概念を整理し、モデルとして表現する
- ここが一番大事で難しそうな部分
- 実際のビジネスをシステムに変換する作業のため、ひらめきやセンスも必要そう
戦術的設計(Tactical Design)
ざっくり言うと、上記戦略的設計をもとに実装を行うことです。
- パターンを使った実装
- エンティティ、値オブジェクト、集約、リポジトリなどのパターンを使ってコードに落とし込む
- 今回は「DDDの全体像」を理解することを目的としているため、これらの用語については本記事では割愛します。
- エンティティ、値オブジェクト、集約、リポジトリなどのパターンを使ってコードに落とし込む
- 継続的なリファクタリング
- ドメインの扱いが変われば、仕様が変わる＝リファクタリングが必要
- 長期的な保守性は、この継続的なリファクタリングによって担保するという思想
DDDの目的
DDDの最終的な目的は、ビジネス価値の最大化です。
たしかに、せっかくシステム開発するならばそこが最大目標になりますよね。
以下3点を重点に、ビジネス価値の最大化を目指すようです。
- 正確な要件実現：ビジネスが本当に求めているものを作る
- 変更に強いシステム：ビジネスの変化に柔軟に対応できる
- 長期的な保守性：継続的なリファクタリングによって担保する
DDDのメリット・デメリット
メリット
- ビジネスとコードの不整合が減る
- ビジネスエキスパートと開発者がユビキタス言語によって緊密にコミュニケーションを取りながら開発を進めるため、「作ったものが求められていたものと違った」という事態を防ぐことができる
- 保守性・拡張性が高い
- 新しい要件や変更が発生した場合でも、システム全体に及ぼす影響を最小限に抑えることができる
- チーム間のコミュニケーションが円滑になる
- 共通言語を使うことで、ビジネス側と開発側の認識のズレを減らせる
デメリット
- 学習コストが高い
- 概念やパターンが多く、チーム全体がDDDを理解するまでに時間がかかる
- 初期の設計時間が長くなる
- ドメインモデリングやユビキタス言語の策定に時間を要する
- 小規模・シンプルなプロジェクトには過剰
- シンプルなシステムには逆に複雑さを増やしてしまう可能性がある
気づき：論文の言語定義とユビキタス言語
DDDを学ぶ中で、ユビキタス言語という概念に強く惹かれました。
論文における言語定義
私は学生時代に論文を書いた経験があるのですが、論文では冒頭で必ず用語の定義を行います。
例えば：
- 「本論文において『利用者』とは、○○システムを使用する企業の従業員を指す」
- 「『処理時間』とは、リクエスト受信からレスポンス返却までの時間とする」
これは、筆者と読者の間で共通認識を作るためです。
ユビキタス言語との共通点
両者の目的は同じだと感じました。
| 論文の言語定義 | ユビキタス言語 |
| 筆者と読者の共通認識 | ビジネス側と開発側の共通認識 |
| 用語の曖昧さを排除 | 認識のズレを防ぐ |
| 論文全体で一貫した用語を使用 | プロジェクト全体で一貫した言葉を使用 |
つまり、論文の言語定義とユビキタス言語は、「共通認識を作る」という本質が同じなんですね。
DDDのユニークな点
ただし、DDDのユビキタス言語には論文の言語定義にはない特徴があります。
①コードにも反映される
ソフトウェアコード（クラス名、クラスメソッド、クラス変数）における言葉や構造はビジネスドメインに一致するため、コードを見るだけでビジネスロジックが理解できます。
例:
- 悪い例： ビジネス側「顧客登録」/ コード
UserCreate - 良い例： 全員が「顧客登録」/ コード
CustomerRegistration
②継続的に育てる（リファクタリングあり）
ユビキタス言語は一度作成したら終わりではなく、プロジェクトの進捗に合わせて継続的に改善していく必要があり、新しい概念や用語が出てきた場合は用語集に追加したり、既存の用語の定義を見直す。とのことです。
論文の場合、執筆・査読・発表という一連のプロセスが終われば基本的に内容を変更することはできないと思いますが、ユビキタス言語はプロジェクトを通じて進化し続けるという点が大きな違いです。
まとめ
ドメイン駆動設計(DDD)について、以下をおさらいしました：
- どんな手法か：ビジネスルールを軸にした設計手法
- 一連の流れ：戦略的設計(モデリング) → 戦術的設計(実装) → 継続的リファクタリング
- メリット：ビジネスとの不整合削減、保守性の向上
- デメリット：学習コスト・初期時間がかかる、小規模案件には過剰
- 目的：ビジネス価値の最大化
個人的には、ユビキタス言語の考え方が論文の言語定義と似ていることに気づき、理解が深まりました。
「共通認識を作る」という本質は同じですが、DDDではそれをコードレベルまで徹底し、さらに継続的に改善していくという点が独特だと感じました。
また、長期的な保守性は継続的なリファクタリングによって担保するという思想があり、DDDは「一度作って終わり」ではなく「育て続ける」設計手法なのだと理解しました。
今後は、この学びを開発の場で生かしつつ、さらにはDDDの具体的なパターン（エンティティや値オブジェクトなど）について学んでいきたいと思います。
参考文献
本記事の執筆にあたり、以下の記事・資料を参考にさせていただきました。
- ふわっと理解するDDD 〜ドメイン駆動設計〜
- ドメイン駆動設計
- Software Design 2024年3月号「ドメイン駆動設計『実践』ガイド」P18-66、技術評論社
株式会社ウイングドアは福岡のシステム開発会社です。
現在、私達と一緒に"楽しく仕事が出来る仲間"として、新卒・中途採用を絶賛募集しています！
ウイングドアの仲間達となら楽しく仕事できるかも？と興味をもった方、
お気軽にお問い合わせ下さい！