DDDという設計方法を知らなかったため調べてみました。
DDD(ドメイン駆動設計)
DDD は『Domain-Driven Design』の略で、エリック・エヴァンス氏によって提唱された概念とのことです。
日本語では『ドメイン駆動設計』と呼ばれています。
この『ドメイン駆動設計』はその名前の通り、「ドメイン」を中心に考える設計のようで、ソフトウェアなどの開発では、この「ドメイン」はソフトウェアが対象としている業務領域のことのようです。
自身の解釈としては、業務を理解した上でソフトウェアの開発を行うという設計手法かなと考えてます。
公式サイト
原則
『ドメイン駆動設計』には、4つの原則があります。
- 業務仕様やビジネスルールの複雑さを紐解き、顧客の課題を正しく理解する
- 業務の専門家とソフトウェアの専門家が協力し、ドメインモデルを作る
- ドメインモデルを明示的に表現するコードを書き、ソフトウェアを作る
- エンジニアである方もそうでない方（業務担当者など）も理解できる共通言語を使って会話する
1. Focus on the core complexity and opportunity in the domain 2. Explore models in a collaboration of domain experts and software experts 3. Write software that expresses those models explicitly 4. Speak ubiquitous language within a bounded context
メリット
業務要件を第一にしたシステムが設計・構築可能
『ドメイン駆動設計』は「業務仕様が主体でコードは業務仕様を反映するもの」という考えなので、「コードに落としにくい機能を削って欲しい」という要望は基本起こりません。
複雑な機能要件も正しく理解しコーディング可能
業務のなかには、要件や処理が複雑なものがよくあります。ドメイン駆動設計ならば複雑な機能要件も整理でき、漏れなく正しく理解することが可能です。業務の流れを正確に把握でき、実務に即した設計を実現できます。
保守性が向上
担当者以外も「業務仕様」が明確なので、変更した際の影響範囲やデータ型の参照関係などが把握しやすいため、保守性が向上します。
デメリット
初期の開発工数がかかる
『ドメイン駆動設計』は業務内容の調査や使用のモデル化に時間がかかります。そのため、保守性は高くなりますが、その分初期の開発コストは大きくなります。
名前を決めるのが大変
『ドメイン駆動設計』を採用すると、クラスの数が多くなります。そのクラスの数だけ、名前を付ける必要があります。
開発の流れ
- step 1: 業務内容の調査
- step 2: 仕様のモデル化
- step 3: 業務ロジックの抽出
- step 4: コード化
- step 5: ブラシュアップ
用語ついて
『ドメイン駆動設計』で使用されている用語をまとめてみました。
ドメインモデル
ドメインモデルは、業務仕様やビジネスルールを図や文章で表現したものです。
ユビキタス言語
ユビキタス言語は、ステークホルダーすべてが理解できる言語です。
ビジネスルール
ビジネスルールは、業務の遂行にあたり守るべき約束事やルール、決定事項などを指します。
ドメインエキスパート
ドメインエキスパートは、問題領域に詳しい専門家を指します。
パターン
パターンは、ドメインモデルを実装し表現する手法を指します。
以下は代表的な項目です。
- 値オブジェクト（ルールを書くことが可能な構造体）
- エンティティ（値オブジェクトに代入できるもの）
- リポジトリ（データベースにアクセスするためのオブジェクト）
- アグリゲート (関連するオブジェクトの集まり)
- ファクトリ (カプセル化するのに役立つパターン)
- リポジトリ (オブジェクトの参照を取得するのに必要なロジックをすべてカプセル化するためのパターン)
エンティティ
エンティティは、属性や振る舞いなどを持ったオブジェクトです。
コンテキストマップ
コンテキストマップは、異なるコンテキスト境界と、それらの関係についての概略を示すための文書です。
