AgentSkillsCN

ddd-module-pattern

基于 DDD 的模块化模式的领域层打包指南。识别技术驱动的打包方式（entities/、value-objects/、services/、repositories/ 等），并推动以领域术语为基础的打包方式。引导领域层中的模块名称成为通用语言的一部分。触发条件：“领域层的包结构”、“DDD 的模块设计”、“希望修正技术驱动的打包方式”、“希望停止使用 entities/ 文件夹”、“领域包的评审”等与领域模块相关的请求。

SKILL.md
--- frontmatter
name: ddd-module-pattern
description: >-
  DDDのモジュールパターンに基づくドメイン層パッケージングガイド。技術駆動パッケージング
  （entities/, value-objects/, services/, repositories/等）を検出し、ドメイン用語ベースの
  パッケージングへの修正を促す。ドメイン層においてモジュール名がユビキタス言語の一部となるよう導く。
  トリガー：「ドメイン層のパッケージ構造」「DDDのモジュール設計」「技術駆動パッケージングを直したい」
  「entities/フォルダをやめたい」「ドメインパッケージのレビュー」等のドメインモジュール関連リクエストで起動。

DDDモジュールパターン

「モジュールはドメインの概念を反映すべきであり、技術的な関心事ではない」 — Eric Evans, Domain-Driven Design (2003)

核心原則

ドメイン層のパッケージ名は、ユビキタス言語の一部である。

問題: 技術駆動パッケージング

code
domain/
  entities/           ← ❌ 技術的分類
    Order.java
    Customer.java
  value-objects/      ← ❌ 技術的分類
    Money.java
    OrderId.java
  services/           ← ❌ 技術的分類
    OrderService.java
問題点影響
ドメイン構造が見えないパッケージを見ても業務の形が分からない
凝集性の低下関連する概念が異なるフォルダに散在
変更の波及1つの機能変更で複数フォルダを横断

解決策: ドメイン駆動パッケージング

code
domain/
  order/              ← ✅ ドメイン概念
    Order.java
    OrderId.java
    OrderItem.java
  customer/           ← ✅ ドメイン概念
    Customer.java
    CustomerId.java
  pricing/            ← ✅ ドメイン概念
    PricingPolicy.java
    Money.java
利点効果
ドメインの可視化パッケージ一覧 = ドメインの主要概念
高凝集関連する型が同一パッケージに集約
局所的変更機能変更が1パッケージで完結

検出パターン

避けるべきパッケージ名（ドメイン層）

code
❌ entities/
❌ value-objects/ (valueobjects/, vo/)
❌ aggregates/
❌ services/
❌ interfaces/
❌ impl/
❌ dto/
❌ domain/types/
❌ domain/core/

レビューチェックリスト

  1. •

    パッケージ名テスト: 業務担当者に通じるか？

    • •✅ order, billing, inventory → 業務用語
    • •❌ entities, services, impl → 技術用語
  2. •

    凝集性テスト: 同じ業務文脈に属するか？

    • •✅ order/ に Order, OrderItem, OrderId
    • •❌ entities/ に Order, Customer, Product
  3. •

    変更影響テスト: 1業務要件で何パッケージ触るか？

    • •✅ 1-2パッケージ
    • •❌ 3パッケージ以上

リファクタリング手順

Step 1: ドメイン概念の抽出

code
現状分析:
- Order, OrderId, OrderItem → 「注文」概念
- Customer, CustomerId → 「顧客」概念
- Money, PricingPolicy → 「価格設定」概念

Step 2: パッケージ境界の決定

code
order/
customer/
pricing/

Step 3: 移動と参照更新

型を新パッケージに移動し、import文を更新。

Step 4: 依存方向の確認

code
✅ order → pricing (注文が価格計算を使う)
❌ pricing → order (循環の可能性)

言語別ガイダンス

詳細は references/language-guides.md を参照。

例外と注意点

共有カーネル (Shared Kernel)

複数ドメインで使われる基本型は共有パッケージに置いてよい：

code
domain/
  shared/           ← 許容される例外
    Money.java
    DateRange.java
  order/
  customer/

ただし shared/ の肥大化は設計見直しのサイン。

インフラストラクチャ層は別ルール

ドメイン層以外では技術駆動パッケージングも許容：

code
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: モジュール内に配置するビルディングブロックの設計