菜单
DDDのモジュールパターンに基づくドメイン層パッケージングガイド。技術駆動パッケージング （entities/, value-objects/, services/, repositories/等）を検出し、ドメイン用語ベースの パッケージングへの修正を促す。ドメイン層においてモジュール名がユビキタス言語の一部となるよう導く。 トリガー：「ドメイン層のパッケージ構造」「DDDのモジュール設計」「技術駆動パッケージングを直したい」 「entities/フォルダをやめたい」「ドメインパッケージのレビュー」等のドメインモジュール関連リクエストで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。GitHub Actions の CI ログ分析、ローカル CI （`./scripts/ci-check.sh`）の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。 ループモード（`/loop 5 /pr-green`）にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。 トリガー：「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。
DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること： - 集約(Aggregate)の新規設計・実装・リファクタリング（どの言語でも） - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定（「AとBは同じ集約にすべきか？」「この集約は大きすぎるか？」） - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断（ドメインイベント、結果整合性、Sagaパターン） - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例：集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。
後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル（deprecation cycle）の 制度化、互換層の局所化（Adapter/Strangler Fig）、契約テスト（CDC）による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存（Java, TypeScript, Go, Python, Rust等すべて）。 トリガー：「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。
getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合（永続化、JSON変換など）に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー：「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。
クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造（ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層）に基づく。特にインフラ層は 横断的関心事（ロギング、設定管理）のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。
| name | ddd-module-pattern |
| description | DDDのモジュールパターンに基づくドメイン層パッケージングガイド。技術駆動パッケージング （entities/, value-objects/, services/, repositories/等）を検出し、ドメイン用語ベースの パッケージングへの修正を促す。ドメイン層においてモジュール名がユビキタス言語の一部となるよう導く。 トリガー：「ドメイン層のパッケージ構造」「DDDのモジュール設計」「技術駆動パッケージングを直したい」 「entities/フォルダをやめたい」「ドメインパッケージのレビュー」等のドメインモジュール関連リクエストで起動。 |
「モジュールはドメインの概念を反映すべきであり、技術的な関心事ではない」 — 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, OrderIdentities/ に Order, Customer, Product変更影響テスト: 1業務要件で何パッケージ触るか？
現状分析:
- Order, OrderId, OrderItem → 「注文」概念
- Customer, CustomerId → 「顧客」概念
- Money, PricingPolicy → 「価格設定」概念
order/
customer/
pricing/
型を新パッケージに移動し、import文を更新。
✅ order → pricing (注文が価格計算を使う)
❌ pricing → order (循環の可能性)
詳細は references/language-guides.md を参照。
複数ドメインで使われる基本型は共有パッケージに置いてよい：
domain/
shared/ ← 許容される例外
Money.java
DateRange.java
order/
customer/
ただし shared/ の肥大化は設計見直しのサイン。
ドメイン層以外では技術駆動パッケージングも許容：
infrastructure/
persistence/ ← 技術的分類OK
jpa/
redis/
10型未満なら1階層で十分。超えたらサブパッケージを検討。
このスキルを使用する際は、以下のスキルも併せて参照すること：
package-design: モジュール設計の基盤となるパッケージ設計原則clean-architecture: ドメインモジュールを配置する層構造domain-building-blocks: モジュール内に配置するビルディングブロックの設計