LASSIC Media らしくメディア
ドメイン駆動設計とは｜DDD導入の考え方と勘所
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
基幹システムや業務アプリの開発を進めるなかで、「要件定義の段階では合意できていたはずの仕様が、開発が進むにつれて現場の実態とズレていく」という悩みを抱える発注担当者やPMは少なくありません。仕様書上の言葉と現場が使う業務用語が微妙に食い違い、追加開発のたびに認識合わせのやり直しが発生する――こうした状態が続くと、システムの保守性は徐々に低下していきます。
こうした課題への向き合い方として近年よく参照されるのが、ドメイン駆動設計（Domain-Driven Design、以下DDD）という設計思想です。DDDは特定のフレームワークやツールを指す言葉ではなく、業務ドメイン（対象領域）の知識をソフトウェアのモデルに反映し、開発者と業務側の関係者が同じ言葉でシステムを語れる状態を目指す考え方を指します。本記事では、DDDの中核概念や戦略的設計・戦術的設計の違い、導入が向くケース・向かないケース、マイクロサービスとの関係、内製・外部委託それぞれで押さえておきたい勘所を、発注側の目線で整理します。
なお本記事は、DDDという設計思想とドメインモデリングの考え方そのものに主題を絞ります。マイクロサービスへの分割手順や移行の進め方、全社的なアーキテクチャの整理手法（エンタープライズアーキテクチャ）は別のテーマとして扱っており、本記事では深入りしない方針です。あくまで、DDDが何を目指す考え方で、どのような場面で効果を発揮しやすいかという判断軸に焦点を当てます。
この記事のポイント
- DDD（ドメイン駆動設計）は、業務ドメインの知識をソフトウェアのモデルに反映し、開発者と業務側が共通言語で対話できる状態を目指す設計思想です。
- ユビキタス言語・境界づけられたコンテキスト・集約といった中核概念を押さえることで、業務ルールが複雑なシステムでもモデルと実装のズレを抑えやすくなります。
- DDDはあらゆるシステムに向くわけではなく、業務の複雑さや体制を踏まえて導入可否を見極め、内製・委託先とも共通言語を持つことが実務上の勘所です。
目次
ドメイン駆動設計（DDD）とは何か
DDDは、ソフトウェア開発において「業務ドメイン（対象領域）の知識をどう扱うか」に主眼を置いた設計思想です*1。特定のプログラミング言語や技術スタックに紐づくものではなく、業務側の関係者（ドメインエキスパート）と開発者が対話を重ねながら、業務の構造をソフトウェアのモデルとして表現していくアプローチを指します。仕様書だけを渡して開発を進めるのではなく、モデルそのものを共通言語として関係者間ですり合わせていく点が特徴です。
なぜ今DDDが注目されやすいのか
DDDという考え方自体は新しいものではありませんが、近年あらためて参照される機会が増えている状況です。背景には、業務ルールの複雑化にともない仕様書だけでは実態を捉えきれないケースが増えていること、機能単位でシステムを分割して開発・運用する構成が広がり、分割の境界線をどう引くかという課題に直面する企業が増えていることが挙げられます。DDDはこうした課題に対して、技術的な分割手法そのものではなく、業務の構造を起点に境界を考える視点を提供します。
DDDの中核概念：ユビキタス言語・境界づけられたコンテキスト・集約
DDDにはいくつかの中核となる概念があります。代表的なものを整理すると、次のとおりです*1。
| 概念 | 意味 | 実務での意義 |
|---|---|---|
| ユビキタス言語 | 開発者と業務側が共通で使う、あいまいさのない用語体系 | 会話・仕様書・コードで同じ言葉を使い、認識のズレを防ぐ |
| 境界づけられたコンテキスト | ある用語やモデルが一貫した意味を持つ範囲 | 同じ言葉でも部門によって意味が異なる問題を明確に区切る |
| ドメイン・サブドメイン | 事業が扱う対象領域全体と、その中の下位領域 | どの領域が事業の核（コアドメイン）かを見極め、注力領域を判断する |
| 集約 | 整合性を保つ単位としてまとめるオブジェクトの集まり | データの更新ルールや一貫性の境界を設計する基準になる |
| ドメインイベント | 業務上意味のある出来事の発生を表す情報 | 「注文が確定した」等の事実を他の処理へ伝える単位になる |
境界づけられたコンテキストの具体例：ECサイトの「商品」
境界づけられたコンテキストは、抽象的な説明だけでは実感しにくい概念です。たとえばECサイトを例にすると、受注を扱うコンテキストでの「商品」は、価格や数量、注文者情報と結びついた存在として扱われます。一方、在庫を扱うコンテキストでの「商品」は、倉庫のどこにいくつあるか、入荷予定はいつかといった情報が中心になる存在です。同じ「商品」という言葉でも、コンテキストが異なれば意味も持つべき属性も変わってきます。この違いを曖昧にしたまま一つの巨大なモデルにまとめようとすると、モデルが肥大化し、変更のたびに影響範囲が広がりやすくなるでしょう。境界づけられたコンテキストを意識して分けておくことで、それぞれのコンテキストが扱う範囲を絞り込み、変更の影響を局所化しやすくなります。
戦略的設計と戦術的設計の違い
DDDの実践は、大きく「戦略的設計」と「戦術的設計」の二つの活動に分けて語られます*1。戦略的設計は、事業全体を俯瞰し、ドメインをサブドメインに整理したうえで境界づけられたコンテキストを定義し、コンテキスト同士の関係を表すコンテキストマップを描く活動です。開発リソースをどこに集中させるか、どのコンテキストを自社で作り込みどこを外部サービスに任せるかといった、方針レベルの意思決定に関わります。
一方の戦術的設計は、一つのコンテキストの中で、エンティティや値オブジェクト、集約、リポジトリ、ドメインイベントといった要素を使ってモデルを実装に落とし込む活動を指します。戦略的設計が「どこで何を作るか」を決める活動だとすれば、戦術的設計は「その中身をどう組み立てるか」を決める活動といえるでしょう。
| 戦略的設計 | 戦術的設計 | |
|---|---|---|
| 主な対象 | 事業全体・複数コンテキストの関係 | 一つのコンテキスト内部のモデル |
| 代表的な成果物 | サブドメイン整理、コンテキストマップ | 集約・エンティティ・リポジトリの設計 |
| 主な関与者 | 経営層・業務責任者・アーキテクト | 開発チーム中心 |
モデリングは業務理解と実装を行き来する
戦略的設計と戦術的設計は、一度きりの手順ではなく、業務理解が深まるたびに繰り返し行き来する性質を持ちます。実装を進めるなかで見えてきた業務の実態を踏まえてモデルを見直し、モデルの変更をユビキタス言語や境界づけられたコンテキストの定義に反映していく循環です。最初から完璧なモデルを作ろうとするのではなく、小さく作って見直していく姿勢が実務では重要になります。
DDD導入が向くケース・向かないケース
DDDはあらゆるシステム開発に一律で当てはまる手法ではありません。向くケースと、無理に採用すると負担が増えやすいケースを整理すると、次のようになります。
- 向くケース――業務ルールが複雑で、ドメイン知識そのものが競争力の源泉になっているシステム
- 向くケース――長期にわたり運用・拡張が続くことが見込まれ、仕様変更が繰り返し発生するシステム
- 向くケース――複数チームが関わる大規模な開発で、担当領域の境界を明確にしたい場合
- 向かないケース――業務ロジックが単純なCRUD中心の小規模システムや、短期間で役目を終える使い捨てのツール
- 向かないケース――ドメインエキスパートが開発に継続的に関わる体制を組めない場合
- 向かないケース――納期優先で、モデリングに割ける時間がほとんど確保できないプロジェクト
DDDを導入するかどうかは、「複雑な業務知識をソフトウェアに正確に反映する必要があるか」を軸に判断するとよいでしょう。すべての機能に同じ精度でモデリングを適用する必要はなく、事業の核となるコアドメインに絞って重点的に取り組む考え方も、DDDの戦略的設計の一部です。
マイクロサービスとの関係：分割の前提になる考え方
DDDとマイクロサービスは、しばしばセットで語られます。境界づけられたコンテキストの単位が、マイクロサービスとしてサービスを分割する際の有力な候補になりやすいためです*1。業務上の意味のまとまりを起点にサービスの境界を引けば、技術的な都合だけで分割するよりも保守しやすい構成になりやすいという考え方です。
ただしDDD自体は、マイクロサービスというアーキテクチャを前提とする手法ではありません。モノリシックな構成のシステムであっても、内部をコンテキストごとにモジュールとして整理する形でDDDの考え方を活かすことは可能です。マイクロサービスへの分割手順や移行の進め方そのものは別テーマとして扱われることが多く、本記事ではDDDという設計思想の側面に絞って触れるにとどめます。分割の是非や具体的な移行計画を検討する段階では、あらためて専門的な検討が必要になるでしょう。
内製・外部委託で押さえておきたい勘所
DDDを取り入れる場合、内製・外部委託のいずれであっても、発注側が押さえておきたい観点があります。
| 観点 | 内製の場合 | 委託の場合 |
|---|---|---|
| ドメインエキスパートの関与 | 業務側の担当者が開発チームと日常的に対話できる体制を組みやすい | 委託先が業務側と直接対話できる場を定期的に確保する必要がある |
| ユビキタス言語の共有 | 社内用語がそのまま通じやすいが、明文化を怠ると属人化しやすい | 用語集や仕様書として明文化し、委託先と認識を合わせる工程が欠かせない |
| モデルの継続的な見直し | 運用しながら随時モデルを調整しやすい | 契約範囲や体制によっては見直しの頻度・費用を事前に取り決めておく必要がある |
| コアドメインの見極め | 事業戦略を理解した社内メンバーが判断しやすい | どの領域が自社の核かを発注側があらかじめ整理し、委託先に伝える必要がある |
特に外部委託の場合、委託先任せにせず、発注側自身がユビキタス言語や境界づけられたコンテキストの整理にどこまで関与するかを事前に決めておくことが重要です。LASSICのような元請会社は、要件定義の段階からドメインの整理に伴走する形でご相談に応じられます。
よくある誤解や失敗パターン
DDDは概念が多く、誤解や中途半端な導入による失敗も見られます。実務でよくあるパターンを整理します。
- DDD＝マイクロサービスだと捉え、業務理解を深めないままサービス分割の議論から入ってしまう――戦略的設計の段階を飛ばすと、境界の引き方に一貫性がなくなりやすくなります
- 集約やリポジトリといった戦術的設計の技術パターンだけを取り入れ、ユビキタス言語やコンテキストの整理を省いてしまう――形だけの導入になり、業務とモデルのズレを防ぐという本来の狙いが薄れます
- ドメインエキスパートが関わらないまま開発者だけでモデリングを進めてしまう――現場の実態と乖離したモデルになりやすくなります
- 最初から全社の全システムにDDDを適用しようとして、モデリングの負荷が大きくなり途中で頓挫してしまう――コアドメインなど重要度の高い領域から段階的に取り組む姿勢が現実的です
まとめ：DDDは業務とシステムの共通言語をつくる考え方
本記事では、ドメイン駆動設計（DDD）について、ユビキタス言語・境界づけられたコンテキスト・集約といった中核概念から、戦略的設計と戦術的設計の違い、導入が向くケース・向かないケース、マイクロサービスとの関係、内製・外部委託それぞれの勘所までを整理しました。DDDは特定の技術やアーキテクチャを指す言葉ではなく、業務ドメインの知識をモデルに反映し、開発者と業務側が同じ言葉でシステムを語れる状態を目指す設計思想です。
すべてのシステムに一律で適用すべき手法ではないからこそ、自社の業務がどれだけ複雑で、どの領域が事業の核なのかを見極めたうえで、導入の要否や範囲を判断することが実務上の出発点になります。
よくある質問
ドメイン駆動設計（DDD）とは、一言で言うとどのような考え方ですか。
業務ドメイン（対象領域）の知識をソフトウェアのモデルに反映し、開発者と業務側の関係者が同じ言葉でシステムを語れる状態を目指す設計思想です。特定のフレームワークや技術を指す言葉ではありません。
DDDを導入すると、マイクロサービス化が必須になりますか。
必須ではありません。境界づけられたコンテキストの単位はマイクロサービス分割の候補になりやすい一方、DDD自体はモノリシックな構成の中でもコンテキストごとにモジュールを整理する形で活かせる考え方です。
小規模なシステムでもDDDは有効ですか。
業務ロジックが単純なCRUD中心のシステムや、短期間で役目を終えるツールでは、DDDのモデリングにかかる労力が見合わないことがあります。業務ルールの複雑さや運用期間を踏まえて導入の要否を判断するとよいでしょう。
ドメインエキスパートとは、具体的に誰を指しますか。
対象となる業務に精通した、業務側の担当者や責任者を指します。開発者だけでモデリングを進めるのではなく、こうした業務側の関係者と継続的に対話しながらモデルを磨き込んでいく点がDDDの特徴です。
外部委託先にDDDを実践してもらう場合、発注側は何を準備すればよいですか。
自社のどの領域が事業の核（コアドメイン）かを整理し、業務用語をできるだけ明文化しておくことが望ましいです。あわせて、委託先が業務側の担当者と定期的に対話できる場を確保できるか、契約段階で確認しておくとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・設計のご相談はLASSICへ
元請（プライムベンダー）として、ドメイン駆動設計を踏まえた要件整理から、複雑な業務ロジックを伴うシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft Azure Architecture Center「ドメイン分析を使用してマイクロサービスを設計する」（https://learn.microsoft.com/ja-jp/azure/architecture/microservices/model/domain-analysis）
