株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
ドメイン駆動設計（DDD）とは？ビジネスの複雑性をソフトウェアで正しく表現する
ドメイン駆動設計（DDD: Domain-Driven Design）は、エリック・エヴァンスが2003年に提唱したソフトウェア設計手法で、ビジネスドメイン（業務領域）の深い理解に基づいてソフトウェアを設計するアプローチです。技術的な関心事ではなく「ビジネスの本質」を中心に据え、ドメインエキスパート（業務の専門家）と開発者が共通の言語（ユビキタス言語）で対話しながら、ビジネスロジックを正確にモデル化します。
DDDは「マイクロサービスをどこで分割するか」を検討する際にも活用できます。Microsoftの設計ガイドは、バウンデッドコンテキストを出発点に、集約やドメインサービスからサービスの候補を選ぶ方法を説明しています。変更の影響を局所化できるか、独立してデプロイできるか、サービス間の結合が強すぎないかを確認し、非機能要件やチーム体制に合わせて境界を調整します。
DDDの戦略的設計と戦術的設計
DDDは「戦略的設計（Strategic Design）」と「戦術的設計（Tactical Design）」の2層で構成されます。
| レイヤー | 焦点 | 主要概念 | 対象者 |
|---|---|---|---|
| 戦略的設計 | ビジネスドメインの全体構造 | バウンデッドコンテキスト、ユビキタス言語、コンテキストマップ | アーキテクト、PdM、ドメインエキスパート |
| 戦術的設計 | ドメインモデルの実装 | エンティティ、値オブジェクト、集約、リポジトリ、ドメインイベント | 開発者 |
戦略的設計：ビジネスの全体像を設計する
ユビキタス言語（Ubiquitous Language）
DDDの最も重要な概念です。ビジネスの用語とコードの用語を統一し、ドメインエキスパートと開発者が同じ言葉で会話できるようにします。「顧客がリクエストを送信する」をビジネス側も開発側も同じ意味で使い、コード上のクラス名やメソッド名にもそのまま反映します。
ユビキタス言語のルール:
- ビジネス用語をそのままコードに使う（技術用語に翻訳しない）
- 用語集（Glossary）を作成し、全チームで共有
- 言語がコードと乖離したらどちらかを修正する
バウンデッドコンテキスト（Bounded Context）
バウンデッドコンテキストは、特定のドメインモデルが有効で一貫性を保つ「意味の境界」です。同じ用語でもコンテキストが異なれば意味が変わります。
| 用語 | 営業コンテキストでの意味 | 配送コンテキストでの意味 |
|---|---|---|
| 「注文」 | 商談から成約に至った契約 | 倉庫から出荷すべき商品リスト |
| 「顧客」 | 見込み客から既存顧客まで | 届け先の住所と連絡先 |
| 「ステータス」 | 商談のフェーズ（提案中→交渉中→成約） | 配送状態（準備中→出荷済→配達完了） |
マイクロサービスの境界設計では、バウンデッドコンテキストを出発点にできます。ただし、常に1対1で対応させるわけではありません。Microsoftのガイドでは、1つのコンテキスト内から複数のサービス候補を選び、非機能要件なども踏まえて分割を検討します。
コンテキストマップ（Context Map）
複数のバウンデッドコンテキスト間の関係を可視化する図です。以下の統合パターンで関係を定義します。
| パターン | 概要 | 例 |
|---|---|---|
| Shared Kernel | 2つのコンテキストがモデルの一部を共有 | 共通の顧客IDの定義を共有 |
| Customer-Supplier | 上流（Supplier）が下流（Customer）にサービス提供 | 注文サービスが在庫サービスに問い合わせ |
| Anti-Corruption Layer | 外部システムとの接続に変換レイヤーを置く | レガシーシステムとの統合 |
| Open Host Service | 公開されたプロトコルでサービスを提供 | REST APIで他コンテキストに機能公開 |
| Published Language | 共有の言語（スキーマ）でデータを交換 | ドメインイベントのJSONスキーマ |
戦術的設計：ドメインモデルを実装する
主要な構成要素
| 概念 | 役割 | 実装例 |
|---|---|---|
| エンティティ（Entity） | 一意のIDで識別されるオブジェクト | Order（注文ID で識別） |
| 値オブジェクト（Value Object） | IDを持たず、値の等価性で比較 | Money（金額+通貨）、Address（住所） |
| 集約（Aggregate） | データ変更の一貫性を保つ単位 | Order + OrderLine（注文と明細） |
| 集約ルート（Aggregate Root） | 集約への唯一のアクセスポイント | OrderがOrderLineの操作を制御 |
| リポジトリ（Repository） | 集約の永続化と取得の抽象化 | OrderRepository.findById() |
| ドメインサービス（Domain Service） | エンティティや値オブジェクトに自然に属さない業務処理（Eric Evansの定義） | TransferService（口座間の送金） |
| ドメインイベント（Domain Event） | ドメイン内で発生した重要な出来事 | OrderPlaced（注文確定）イベント |
集約設計の原則
- 小さく保つ: 集約は可能な限り小さく設計し、トランザクションの範囲を最小化
- 集約間の参照はIDのみ: 他の集約への直接参照を持たず、IDで参照する
- 結果整合性の活用: 集約間の整合性はドメインイベントによる結果整合性で実現
- 集約ルート経由のアクセス: 集約内のオブジェクトには必ず集約ルート経由でアクセス
DDDとマイクロサービスの接続
バウンデッドコンテキスト→マイクロサービスへのマッピング
- ドメインの分析: ビジネスプロセスとドメインエキスパートへのインタビューからドメインを理解
- バウンデッドコンテキストの特定: ユビキタス言語の境界でコンテキストを分割
- コンテキストマップの作成: コンテキスト間の関係と統合パターンを設計
- マイクロサービスへのマッピング: 各バウンデッドコンテキスト内の集約やドメインサービスから候補を選び、非機能要件・チーム体制に合わせてサービスに分割して実装
- ドメインイベントによる連携: サービス間をイベント駆動（Kafka等）で疎結合に連携
DDD導入のステップ
ステップ1: イベントストーミングの実施
イベントストーミングは、ドメインエキスパートと開発者が一堂に会し、ビジネスプロセス全体を「ドメインイベント」の連鎖としてポストイットで可視化するワークショップ手法です。公式説明にも複数の目的に応じた進め方が示されています。例えば対象範囲を絞った2〜4時間のセッションを設け、業務の流れとバウンデッドコンテキストの候補を洗い出します。これは進行例であり、業務全体を把握するまでの回数や時間は、対象の広さや参加者に応じて調整します。
ステップ2: コアドメインの特定
全てのドメインに同じ投資をするのではなく、「コアドメイン」（競争優位の源泉となるビジネスロジック）を特定し、そこにDDDの最も深い設計を適用します。
| 分類 | 概要 | 設計投資 | 例 |
|---|---|---|---|
| コアドメイン | 競争優位の源泉 | 最大（DDD完全適用） | レコメンドエンジン、料金計算 |
| サポートドメイン | コアを支えるが差別化要因ではない | 中（簡略化されたDDD） | ユーザー管理、通知機能 |
| 汎用ドメイン | 業界共通の標準的な機能 | 最小（SaaS/OSSで代替） | 認証、メール配信、決済 |
ステップ3: ユビキタス言語の構築
ドメインエキスパートと開発者で用語集を共同作成し、コード、ドキュメント、会話の全てで統一的に使用します。用語集はWiki/Confluenceなどで管理し、定期的にレビューしてください。
ステップ4: 戦術的パターンの段階的適用
全コードベースにDDDを適用する必要はありません。コアドメインから段階的に適用し、サポートドメインには簡略化された形で、汎用ドメインには適用しない判断が現実的です。
DDDの課題と対策
| 課題 | 内容 | 対策 |
|---|---|---|
| 学習コスト | 概念が抽象的で理解に時間がかかる | イベントストーミングから実践的に学ぶ |
| ドメインエキスパートの不在 | 開発者だけではドメインモデルが不正確に | 業務に詳しいPdMやユーザーの巻き込み |
| 過度な設計 | シンプルなCRUDにDDDを適用して複雑化 | コアドメインにのみ本格適用 |
| チーム間の合意形成 | ユビキタス言語の統一が困難 | イベントストーミングで可視化、用語集の運用 |
2026年に検討するDDDの関連技術
AI支援によるドメインモデリング
AIによるモデル作成支援の例として、Miroは文章からER図の初期構造を生成する機能を紹介しています。ER図はデータの関係を表すもので、DDDのドメインモデル全体を自動的に決めるものではありません。DDDでの活用案としては、ビジネス文書、議事録、要件定義書から業務用語や処理を整理し、エンティティ・値オブジェクト・イベントの候補を検討する「叩き台」に使えます。人間のドメインエキスパートが業務上の意味を確認し、修正にかかる時間も含めて効率を評価してください。
DDDとイベント駆動設計の組み合わせ
ドメインイベントを中心に据えてDDDとマイクロサービスを組み合わせる設計も選択肢になります。進め方の一例は、イベントストーミングで業務を整理し、ドメインイベントを設計して、Kafkaなどでイベント駆動の連携を実装する流れです。Kafkaの採用やこの手順はDDDの必須条件ではなく、整合性・配信順序・運用負荷などの要件に応じて判断します。
DDDとデータメッシュの融合
データメッシュの提唱者Zhamak Dehghaniの解説は、分析用データの所有権を分散する候補として、業務ドメインのバウンデッドコンテキストを挙げています。DDDでサービス境界を検討し、データメッシュで分析用データの所有権を整理する組み合わせが考えられます。業務処理と分析用データでは責務が異なるため、サービスの分割とデータ所有権を常に1対1にそろえる必要はありません。
よくある質問（FAQ）
Q. DDDは全てのプロジェクトに必要ですか？
いいえ。DDDは「ビジネスロジックの複雑性が高い」プロジェクトで最も効果を発揮します。シンプルなCRUDアプリケーション、データのパイプライン処理、UIが中心のフロントエンドアプリには過剰設計になりえます。「ドメインのルールが複雑で、ビジネスの変化に追従し続ける必要がある」ケースでDDDの導入価値が高まります。
Q. DDDの学習にはどのくらい時間がかかりますか？
基本概念（ユビキタス言語、バウンデッドコンテキスト）の理解に1〜2週間、戦術的パターン（エンティティ、集約、リポジトリ等）の実践に1〜2か月、プロジェクトでの本格適用と習熟に6か月〜1年が目安です。最も効果的な学習方法は「イベントストーミングのワークショップに参加し、実際のプロジェクトで適用すること」です。
Q. DDDとクリーンアーキテクチャの関係は？
DDDの戦術的パターン（エンティティ、リポジトリ等）とクリーンアーキテクチャ（ヘキサゴナルアーキテクチャ、レイヤードアーキテクチャ等）は補完関係にあります。DDDが「何をモデル化するか」を決め、クリーンアーキテクチャが「コードをどう構造化するか」を決めます。DDDのドメインモデルをクリーンアーキテクチャの中心（ドメイン層）に配置するのが一般的なパターンです。
まとめ：DDDで「ビジネスの本質」をコードに宿す
ドメイン駆動設計は、ソフトウェアの複雑性を「技術の問題」ではなく「ビジネスの理解の問題」として捉え、ドメインエキスパートと開発者の協働でビジネスロジックを正確にモデル化する設計思想です。マイクロサービスの境界設計、イベント駆動アーキテクチャとの融合、データメッシュとの接続など、モダンなアーキテクチャの基盤としてDDDの重要性は増す一方です。
renueでは、DDDを活用したシステム設計からマイクロサービスアーキテクチャの構築、イベントストーミングのファシリテーションまで、企業のソフトウェア設計を包括的に支援しています。システムの複雑性管理やアーキテクチャ設計でお悩みの方は、ぜひお気軽にご相談ください。
株式会社renueでは、AI導入戦略の策定からDX推進のコンサルティングを提供しています。お気軽にご相談ください。
