株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
ドメイン駆動設計（DDD）とは？基本概念
ドメイン駆動設計（Domain-Driven Design、DDD）は、エリック・エヴァンスの2003年刊の著書『Domain-Driven Design: Tackling Complexity in the Heart of Software』で体系化されたソフトウェア設計の考え方です。その核心は「ビジネスの課題（ドメイン）を中心にソフトウェアを設計する」という考え方にあります。
従来のシステム開発では技術的な都合がシステム設計を主導しがちでしたが、DDDでは業務の専門家（ドメインエキスパート）と開発者が緊密に協力し、ビジネスの言葉をコードに忠実に反映させることを最優先とします。複雑なビジネスルールを持つエンタープライズシステム・ECサイト・SaaSプロダクトなどで特に効果を発揮します。
DDDの基本概念・用語
以下の用語は、著者が公開する『Domain-Driven Design Reference』を参照しながら、業務上の例とともに説明します。
ユビキタス言語（Ubiquitous Language）
開発者とドメインエキスパートが共有する共通の言語体系です。「注文」「請求」「顧客」などのビジネス用語を、会話・ドキュメント・コードで一貫して使用します。ユビキタス言語を継続的に確かめることで、認識ズレによるバグや仕様の解釈違いを減らすことを目指します。
境界付きコンテキスト（Bounded Context）
ユビキタス言語が一貫して適用される境界です。大きなシステムを意味のある単位（コンテキスト）に分割し、各コンテキストで独自のドメインモデルを持ちます。例えば「注文管理」と「在庫管理」はそれぞれ異なるコンテキストを持ち、「商品」という概念も各コンテキストで異なる属性・ルールを持つことがあります。
ドメインモデル
ビジネスの概念・ルール・プロセスをオブジェクトとして表現したモデルです。ドメインモデルはコードとして実装され、ビジネスの変化に追従して継続的に進化します。
DDDの戦術的パターン
MicrosoftのDDD解説も、エンティティ・値オブジェクト・集約・ドメインサービス等を、境界付きコンテキスト内のモデルを具体化するパターンとして説明しています。
エンティティ（Entity）
一意のIDで識別されるオブジェクトです。同じ属性値を持っていても、IDが異なれば別のオブジェクトとして扱います。例えば「顧客A（ID:001）」と「顧客B（ID:002）」は同姓同名であっても別エンティティです。エンティティは状態が変化してもIDで追跡し続けることができます。
値オブジェクト（Value Object）
IDを持たず、属性値によって等価性が判断されるオブジェクトです。「住所」「金額」「座標」などがその例です。値オブジェクトは不変（イミュータブル）に設計することが推奨されます。同じ住所であれば、どのインスタンスも等価として扱います。
集約（Aggregate）
関連するエンティティと値オブジェクトをまとめ、整合性を維持する境界を定めたクラスターです。集約は1つのルートエンティティ（集約ルート）を持ち、外部から内部の状態を変更するときは、ルートが整合性のルールを守る責任を担うよう設計します。この境界に合わせてトランザクションを設計し、集約をまたぐ更新の整合性は別途扱います。
リポジトリ（Repository）
集約の永続化と取得を担当するインターフェースです。著者の参考資料のRepositories（本文17ページ）では、必要な集約ルートへのアクセスを提供し、保存・問い合わせの技術を隠す考え方が説明されています。データベースの具体的な実装詳細を隠蔽し、ドメインモデルがインフラ技術に依存しないようにします。
ドメインサービス（Domain Service）
エンティティや値オブジェクトに自然に属さないドメインロジックを担当するサービスです。「2つの口座間の振替処理」のように、複数の集約にまたがる操作を表現するのに適しています。
ドメインイベント（Domain Event）
ドメイン内で発生した重要な事象を表すオブジェクトです。「注文が確定した」「在庫が不足した」などのイベントをドメインオブジェクトとして明示的に表現することで、イベント駆動アーキテクチャとの親和性が高まります。
DDDの戦略的パターン
著者の参考資料のContext Map・Anticorruption Layer（本文29・34ページ）では、コンテキスト間の関係や翻訳層の役割が説明されています。
コンテキストマッピング
複数の境界付きコンテキスト間の関係を図で表現する手法です。上流・下流関係・共有カーネル・腐敗防止層などのパターンを用いてコンテキスト間の連携方法を設計します。
腐敗防止層（Anti-Corruption Layer）
外部システムや異なるコンテキストからのデータ・概念が自分のドメインモデルを「汚染」しないよう保護する層です。外部システムとのインターフェース部分に変換ロジックを置き、自分のコンテキストのモデルの純粋性を保ちます。
DDDのメリット・デメリット
メリット
- ビジネスの変化に追従しやすい柔軟な設計を実現
- 開発者とビジネス担当者の認識ズレを減らせる
- 複雑なビジネスロジックをコードで正確に表現できる
- マイクロサービスアーキテクチャとの親和性が高い
デメリット
- 習得コストが高い（エンティティ・値オブジェクト・集約の設計判断が難しい）
- シンプルなCRUDアプリにはオーバーエンジニアリングになりやすい
- ドメインエキスパートとの密な協力が必要
AIシステム開発へのDDDの適用
AI・機械学習システムの開発にもDDDは応用できます。「モデル」「実験」「特徴量」「予測結果」などをドメインオブジェクトとして設計することで、AIシステムのビジネスロジックを明確に表現できます。renueは、ビジネス要件をAIシステムに反映するため、業務の言葉とモデルを対応付け、DDDの考え方を設計に活かすことが有効だと考えています。
AIシステムのドメイン設計はrenueへ
renueはDDDとクリーンアーキテクチャを活用したAIシステム設計・実装を支援しています。ビジネス要件をコードに正確に反映させた高品質なAIシステムを構築します。
無料相談はこちら参考資料
Microsoft「マイクロサービスの境界を特定する」、Robert C. Martin「The Clean Architecture」。