ドメイン駆動設計（DDD）

1. 概要

ドメイン駆動設計（DDD: Domain-Driven Design） は、ソフトウェア設計の手法の一つであり、ビジネスロジック（ドメイン）を中心にシステムを構築する考え方です。

---

初学者向け

DDDとは？

DDDは、ビジネス上の課題（ドメイン）を解決するために、ソフトウェアの構造をドメインに基づいて設計する方法です。単なる技術的な設計ではなく、ビジネスの専門家（ドメインエキスパート）とエンジニアが協力してシステムを作ることが特徴です。

項目	説明
ドメイン	ビジネス領域（例：ECサイトなら「注文管理」）
エンティティ	IDを持ち、一意性を持つオブジェクト（例：注文）
値オブジェクト	IDを持たず、属性だけで判断されるオブジェクト（例：金額）
集約	いくつかのエンティティをまとめた単位（例：注文とその明細）
リポジトリ	データを永続化するための仕組み（例：データベース）
サービス	エンティティに持たせるべきでないロジックを実装する層
ユビキタス言語	開発者とビジネス側が共通で使う言葉

図で理解するDDDの概念

classDiagram
    class Entity {
        - ID
        - 属性
    }
    class ValueObject {
        - 属性のみ
    }
    class Aggregate {
        - ルートエンティティ
        - 複数のエンティティを管理
    }
    class Repository {
        - エンティティの永続化
    }
    Entity --|> ValueObject
    Aggregate --|> Entity
    Aggregate --|> Repository

---

専門者向け

DDDの原則

• 境界づけられたコンテキスト（Bounded Context）：システムを小さな意味的領域に分割し、それぞれの領域を独立して管理する
• ユビキタス言語（Ubiquitous Language）：開発チームとビジネス側が共通の用語を使用することで、認識のずれを防ぐ
• アグリゲート（Aggregate）：一貫性を保つためのデータのグループ単位を定義し、外部からの直接変更を制限する

DDDの実装例（TypeScript）

class Order {
    private orderId: string;
    private amount: number;

    constructor(orderId: string, amount: number) {
        this.orderId = orderId;
        this.amount = amount;
    }

    getOrderId(): string {
        return this.orderId;
    }
    getAmount(): number {
        return this.amount;
    }
}

DDDのメリット・デメリット

メリット	デメリット
ビジネスロジックの明確化	学習コストが高い
ソフトウェアの保守性向上	小規模開発にはオーバースペックになる可能性
開発者とビジネス側の認識統一	設計に時間がかかる

---

まとめ

DDDは、単なる技術的なアプローチではなく、ビジネスと開発の間に共通認識を持たせるための設計手法です。適切に適用することで、スケーラブルで保守しやすいシステムを構築できます。