mcpField
D
ddd-module-pattern

ddd-module-pattern

github.com/j5ik2oDevelopment8036 installsUpdated 27w ago
Repository

About ddd-module-pattern

ddd-module-pattern is a skill for developers structuring domain-layer packages with domain concepts rather than technical categories. It includes checks and refactoring guidance for improving cohesion and keeping changes localized.

Key features

  1. 01Domain-oriented package structure
  2. 02Checks for technical package names
  3. 03Cohesion and change-impact review
  4. 04Steps for extracting domain concepts
  5. 05Guidance on shared and small domains

Use cases

  1. 01Reviewing domain-layer package names
  2. 02Refactoring technical packages around business concepts
  3. 03Keeping related domain types together

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/j5ik2o/okite-ai --skill ddd-module-pattern

After installing, type/ddd-module-patternin Claude Code to confirm it loaded.

Bundled filesreferences/language-guides.md

Details

From the project README

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

Comments

Markdown supported