本文へ移動
cccskills
無料GitHub で公開

domain-model-extractor

既存コード（DDDを前提としていない）を分析し、ドメインモデル（集約、ローカルエンティティ、 値オブジェクト、ドメインサービス）を擬似コード付きで提案するスキル。プロパティ・メソッド・ 不変条件・集約境界を含む設計を提案する。対象言語: 言語非依存。

トリガー：「既存コードからドメインモデルを抽出して」「このコードをDDDで再設計したい」 「ドメインモデルを提案して」「集約を見つけたい」「DDDに移行したい」 「既存コードを分析してドメインモデルを作って」「レガシーコードをDDDに」 といった既存コード分析・ドメインモデル抽出リクエストで起動。

j5ik2o/okite-ai
インストール方法を見る

含まれるファイル（3）

  • SKILL.md5.9 KB
  • references/analysis-heuristics.md3.6 KB
  • references/output-template.md3.5 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Domain Model Extractor

既存の非DDDコードを分析し、DDDのビルディングブロック（集約・ローカルエンティティ・値オブジェクト・ドメインサービス）を擬似コード付きで提案する。

分析ワークフロー

Phase 1: スコープ確認

ユーザーに以下を確認する：

  • 分析対象のディレクトリ/ファイル範囲
  • ドメインの概要（何を扱うシステムか）
  • 特に関心のある領域（あれば）

Phase 2: 既存コードの探索

以下の順序で情報を収集する：

Step 1: 構造の把握

  • ディレクトリ構造を確認し、モジュール/パッケージの全体像を掴む
  • 主要なクラス/構造体/型を一覧化する

Step 2: データ構造の分析

  • DB スキーマ（マイグレーション、ORMモデル等）があれば確認
  • 主要なクラス/構造体のフィールド・プロパティを確認
  • データ間の参照関係（外部キー、IDフィールド等）を把握

Step 3: ビジネスロジックの所在特定

  • バリデーションロジックの散在箇所を特定
  • 条件分岐の多いメソッドを特定（ビジネスルールの候補）
  • 複数エンティティにまたがる操作を特定

Step 4: トランザクション境界の分析

  • 同一トランザクションで更新されるデータ群を特定
  • これが集約境界の最重要手がかりとなる

Phase 3: ドメインモデルの導出

収集した情報を基に、以下の順序でモデルを導出する。 詳細なヒューリスティクスは references/analysis-heuristics.md を参照。

導出順序:

  1. 値オブジェクト - プリミティブ型で表現されたドメイン概念、検証ロジックの散在箇所から
  2. 集約 - トランザクション境界、CRUDの単位、不変条件の範囲から
  3. ローカルエンティティ - 集約内部でのみ意味を持つ、IDを持つオブジェクト
  4. ドメインサービス - 複数集約にまたがる操作、特定オブジェクトに属さないルール

各モデルに含める情報:

  • プロパティ（型情報付き）
  • ファクトリメソッド（生成時の検証）
  • コマンドメソッド（状態変更操作、不変で新インスタンスを返す）
  • クエリメソッド（状態参照操作）
  • 不変条件（集約が常に満たすべきルール）

Phase 4: 提案ドキュメントの出力

references/output-template.md のテンプレートに従い、以下を含むMarkdownドキュメントを生成する：

  1. 概要（分析対象、発見したモデル数）
  2. 集約ごとのセクション（擬似コード付き）
  3. 値オブジェクト一覧（擬似コード付き）
  4. ドメインサービス一覧（擬似コード付き）
  5. 集約関連図（テキストベース）
  6. 既存コードとの対応表

出力例（抜粋）

以下は EC サイトの注文管理コードを分析した場合の出力イメージ（集約1つ分）:

Aggregate Order {
  id: OrderId
  customerId: CustomerId        // 他集約へのID参照
  items: List<OrderItem>        // ローカルエンティティ
  status: OrderStatus           // 値オブジェクト
  shippingAddress: Address      // 値オブジェクト

  // Invariants: items は1件以上、合計金額は0より大きい

  static create(customerId, firstItem, address): Order
  addItem(item: OrderItem): Order       // returns 新しいインスタンス
  removeItem(itemId: OrderItemId): Order
  submit(): Order                        // status を Submitted に変更
  totalAmount(): Money
}

分類判断基準

判断ポイント集約ローカルエンティティ値オブジェクト
独自のIDを持つかYes（ルートID）Yes（ローカルID）No
単独で取得されるかYesNo（親経由）No
ライフサイクルがあるかYes親に従属なし（不変）
同一性で比較するかYes（ID）Yes（ID）No（値で比較）

注意事項

  • 既存コードの1クラス = 1集約とは限らない。複数クラスが1集約になることも、1クラスが複数に分割されることもある
  • テーブル構造に引きずられすぎない。テーブルは永続化の都合であり、ドメインモデルの構造と一致するとは限らない
  • 過度に細かい値オブジェクトを作りすぎない。ドメインで意味のある単位のみ
  • 集約は小さく保つ（Vernon's Rule）。迷ったら分割する方向で

関連スキル（併読推奨）

このスキルを使用する際は、以下のスキルも併せて参照すること：

  • domain-building-blocks: 抽出対象となるビルディングブロックの定義と設計
  • aggregate-design: 集約境界の特定と設計ルール
  • cqrs-aggregate-modeling: 読み取り責務が混在する集約の分離指針

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

aggregate-design

無料日本語概要

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、集約の分割、真の不変条件

j5ik2o/okite-ai802026年4月25日 更新

aggregate-transaction-boundary

無料日本語概要

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

backward-compat-governance

無料日本語概要

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル（deprecation cycle）の 制度化、互換層の局所化（Adapter/Strangler Fig）、契約テスト（CDC）による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存（Java, TypeScript, Go, Python, Rust等すべて）。 トリガー：「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

breach-encapsulation-naming

無料日本語概要

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合（永続化、JSON変換など）に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー：「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

clean-architecture

無料日本語概要

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造（ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層）に基づく。特にインフラ層は 横断的関心事（ロギング、設定管理）のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

j5ik2o/okite-ai802026年4月25日 更新

cqrs-aggregate-modeling

無料日本語概要

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー：「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

j5ik2o のスキルをすべて見る

このスキルの問題を報告する