DDDの原点：Eric Evans『ドメイン駆動設計』が変えた設計の考え方

ドメイン駆動設計（DDD）は2003年に Eric Evans の著書から始まった。20年以上が経過した今、DDDの用語はマイクロサービス設計やクリーンアーキテクチャの文脈でも頻繁に登場する。『エリック・エヴァンスのドメイン駆動設計』は原典として今も読まれ続けているが、分厚く難解な書籍として知られ、全体像を掴むまでに時間がかかる。

1. DDDが解こうとした問題

Evans がDDDで解こうとした問題の本質は「複雑さ」だ。

ビジネスロジックが複雑であるとき、その複雑さをコードで正確に表現するために何が必要か——この問いへの答えがDDDの出発点だ。複雑さはデータベース設計やUI実装の問題ではなく、ビジネスのドメイン（問題領域）そのものにある。

技術的な実装の問題を解くことより、ビジネスのルールと構造をコードとして正確にモデル化することを優先する——この優先順位の転換が、DDDの根幹にある考え方だ。

2. ユビキタス言語：開発者とビジネス担当者が共通の言語を持つ

本書の最初の柱がユビキタス言語（Ubiquitous Language）だ。

開発チームとビジネス担当者が同じ言葉を使う。コードの中の変数名・クラス名・メソッド名が、ビジネスの会話で使われる用語と一致している。このことで、仕様書とコードの間の翻訳コストが下がり、要件の誤解が減る。

ユビキタス言語は一度決めたら終わりではなく、ドメインの理解が深まるにつれて進化する。モデルと言語は同時に洗練される。

3. 境界づけられたコンテキストで「意味の一貫性」を守る

大きなシステムに単一のモデルを適用しようとすると、同じ言葉が異なる意味を持つ問題が生まれる。「顧客」という概念が、販売部門と配送部門と請求部門で異なる属性を持つことは珍しくない。

境界づけられたコンテキスト（Bounded Context）は、モデルが一貫した意味を持つ境界を明示的に定義する。各コンテキスト内では、そのコンテキストに固有のモデルが支配する。コンテキスト間の関係は「コンテキストマップ」として可視化する。

マイクロサービスとBounded Contextの対応関係は現代の設計論でも重要なテーマで、Evans の提唱がマイクロサービス設計の土台になっている面がある。

4. 集約：整合性の境界を設計する

戦術的設計の中でも特に影響力が大きいのが集約（Aggregate）の概念だ。

集約は「不変条件（ビジネスルール）をまとめて管理する単位」だ。集約のルートエンティティを通じてのみ内部の変更を行うことで、整合性が崩れる経路を限定できる。

集約の境界を小さく保つことが重要で、大きすぎる集約はパフォーマンスと整合性の両面で問題を起こしやすい。何を一つの集約として扱い、何を別の集約として分けるかは、ドメインのビジネスルールの理解に基づく判断だ。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。