1.ドメイン駆動設計の基本的な考え方
-
「ドメイン」とは何か？
- ドメインとは「そのシステムが解決しようとする業務の世界」のことです。たとえば、銀行システムなら「お金の預け入れや送金」、オンラインショップなら「商品購入や在庫管理」がドメインです。
- ドメイン駆動設計では、「その業務の仕組みやルール（ドメイン）」を理解することが最優先になります。
-
ビジネスの専門家と開発者が協力する
- DDDでは、ビジネスの専門家（顧客や業務担当者）と開発者が一緒に議論し、システムの中核となる業務（ドメイン）を深く理解して設計を進めます。
- 専門家から聞いた業務ルールを正しく反映させたシステムを作ることが目標です。
2. DDDを構成する重要な要素
ドメイン駆動設計では、いくつかの「核となる考え方」があります。以下はその中でも重要な3つです。
(1) ユビキタス言語（Ubiquitous Language）
-
何をするもの？
- ドメイン駆動設計では、開発者と業務担当者が共通して使う「言葉」を統一します。これを「ユビキタス言語」と呼びます。
-
なぜ必要？
- 「業務担当者と開発者で使う言葉が違うと誤解が生まれる」ことを防ぎます。
- たとえば、「顧客」という言葉を「ユーザー」と混同しないよう、明確に定義します。
(2) エンティティとバリューオブジェクト
-
エンティティ（Entity）
- 業務上「一意の識別子」を持つもの。
- 例: 図書館の「利用者」や「図書」はエンティティです。利用者IDや図書IDで特定できるからです。
-
バリューオブジェクト（Value Object）
- 業務上「単なる値として扱うもの」。
- 例: 「住所」や「日付」は値としてシステムに扱われ、個別のIDを必要としません。
(3) 集約（Aggregate）
-
何をするもの？
- 業務で扱うデータを「まとまり」としてグループ化し、外部とのやり取りをシンプルにします。
- 例: 図書館システムなら、「貸出」という集約の中に「利用者」「図書」「返却期限」が含まれる形。
-
メリット
- データの管理がシンプルになり、システム全体の複雑さを減らせます。
3. DDDでシステムを作る流れ
大きく分けると、以下の流れでシステムを設計・構築します。
(1) ドメインの理解
- 業務の専門家（顧客）にインタビューし、業務のルールや仕組みを深く理解します。
- ユビキタス言語を作り、開発者と顧客が「共通言語」を使えるようにします。
(2) ドメインモデルの設計
- 業務ルールをもとに、エンティティ、バリューオブジェクト、集約などを設計します。
- 例: 図書館の「貸出モデル」には、「利用者」「図書」「貸出日」「返却期限」が含まれます。
(3) 実装
- 設計したドメインモデルをコードに落とし込みます。
- 業務ルールが変更された場合も簡単に対応できる設計を目指します。
4. DDDのメリットと課題
メリット
- 業務ルールに忠実なシステムを作れる。
- システムが拡張しやすく、変更に強くなる。
- 開発者と業務担当者の意思疎通が良くなる。
課題
- ドメイン駆動設計を実践するには、業務の深い理解と設計力が求められる。
- 小規模なプロジェクトでは、DDDを適用するコストが高い場合がある。