DDDモジュールパターン
「モジュールはドメインの概念を反映すべきであり、技術的な関心事ではない」
— Eric Evans, Domain-Driven Design (2003)
核心原則
ドメイン層のパッケージ名は、ユビキタス言語の一部である。
問題: 技術駆動パッケージング
domain/
entities/ ← ❌ 技術的分類
Order.java
Customer.java
value-objects/ ← ❌ 技術的分類
Money.java
OrderId.java
services/ ← ❌ 技術的分類
OrderService.java
| 問題点 | 影響 |
|---|
| ドメイン構造が見えない | パッケージを見ても業務の形が分からない |
| 凝集性の低下 | 関連する概念が異なるフォルダに散在 |
| 変更の波及 | 1つの機能変更で複数フォルダを横断 |
解決策: ドメイン駆動パッケージング
domain/
order/ ← ✅ ドメイン概念
Order.java
OrderId.java
OrderItem.java
customer/ ← ✅ ドメイン概念
Customer.java
CustomerId.java
pricing/ ← ✅ ドメイン概念
PricingPolicy.java
Money.java
| 利点 | 効果 |
|---|
| ドメインの可視化 | パッケージ一覧 = ドメインの主要概念 |
| 高凝集 | 関連する型が同一パッケージに集約 |
| 局所的変更 | 機能変更が1パッケージで完結 |
検出パターン
避けるべきパッケージ名（ドメイン層）
❌ entities/
❌ value-objects/ (valueobjects/, vo/)
❌ aggregates/
❌ services/
❌ interfaces/
❌ impl/
❌ dto/
❌ domain/types/
❌ domain/core/
レビューチェックリスト
-
パッケージ名テスト: 業務担当者に通じるか？
- ✅
order, billing, inventory → 業務用語
- ❌
entities, services, impl → 技術用語
-
凝集性テスト: 同じ業務文脈に属するか？
- ✅
order/ に Order, OrderItem, OrderId
- ❌
entities/ に Order, Customer, Product
-
変更影響テスト: 1業務要件で何パッケージ触るか？
リファクタリング手順
Step 1: ドメイン概念の抽出
現状分析:
- Order, OrderId, OrderItem → 「注文」概念
- Customer, CustomerId → 「顧客」概念
- Money, PricingPolicy → 「価格設定」概念
Step 2: パッケージ境界の決定
order/
customer/
pricing/
Step 3: 移動と参照更新
型を新パッケージに移動し、import文を更新。
Step 4: 依存方向の確認
✅ order → pricing (注文が価格計算を使う)
❌ pricing → order (循環の可能性)
言語別ガイダンス
詳細は references/language-guides.md を参照。
例外と注意点
共有カーネル (Shared Kernel)
複数ドメインで使われる基本型は共有パッケージに置いてよい：
domain/
shared/ ← 許容される例外
Money.java
DateRange.java
order/
customer/
ただし shared/ の肥大化は設計見直しのサイン。
インフラストラクチャ層は別ルール
ドメイン層以外では技術駆動パッケージングも許容：
infrastructure/
persistence/ ← 技術的分類OK
jpa/
redis/
小規模ドメイン
10型未満なら1階層で十分。超えたらサブパッケージを検討。
参考文献
- Evans, Eric. "Domain-Driven Design" (2003), Chapter 5: Modules
- Vernon, Vaughn. "Implementing Domain-Driven Design" (2013), Chapter 9: Modules
関連スキル（併読推奨）
このスキルを使用する際は、以下のスキルも併せて参照すること：
package-design: モジュール設計の基盤となるパッケージ設計原則clean-architecture: ドメインモジュールを配置する層構造domain-building-blocks: モジュール内に配置するビルディングブロックの設計