ddd-module-pattern

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

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "ddd-module-pattern" with this command: npx skills add j5ik2o/okite-ai/j5ik2o-okite-ai-ddd-module-pattern

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/

レビューチェックリスト

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

    • order, billing, inventory → 業務用語
    • entities, services, impl → 技術用語
  2. 凝集性テスト: 同じ業務文脈に属するか?

    • order/Order, OrderItem, OrderId
    • entities/Order, Customer, Product
  3. 変更影響テスト: 1業務要件で何パッケージ触るか?

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

リファクタリング手順

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

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

cross-aggregate-constraints

No summary provided by upstream source.

Repository SourceNeeds Review
General

domain-model-extractor

No summary provided by upstream source.

Repository SourceNeeds Review
General

first-class-collection

No summary provided by upstream source.

Repository SourceNeeds Review
General

aggregate-design

No summary provided by upstream source.

Repository SourceNeeds Review