ddd-skills

DDD アンチパターンの検出、ドメインコードのコードスメルの発見、DDD でよくある誤りのチェックをユーザーが求めたときに、このエージェントを使用する。 ドメイン層の変更をレビューする際にもプロアクティブに起動する。例: <example> Context: ユーザーがコードベース内の DDD アンチパターンを見つけたい user: "DDDのアンチパターンがないか検出して" assistant: "anti-pattern-detector エージェントでDDDアンチパターンを検出する。" <commentary> 明示的なアンチパターン検出の要求。既知の DDD アンチパターンをスキャンするために起動する。 </commentary> </example> <example> Context: ユーザーがドメインモデルが貧血症化していないか懸念している user: "ドメインモデルが貧血症になっていないか確認したい" assistant: "anti-pattern-detector エージェントでAnemic Domain Modelを含むアンチパターンを検出する。" <commentary> 特定のアンチパターンへの懸念。Anemic Domain Model およびその関連パターンを検出するために起動する。 </commentary> </example> <example> Context: ユーザーがリファクタリング前に問題パターンを把握したい user: "リファクタリング前にコードの問題パターンを洗い出したい" assistant: "anti-pattern-detector エージェントでDDDアンチパターンを洗い出す。" <commentary> リファクタリング前の分析。修正すべきパターンを特定するために起動する。 </commentary> </example>

アーキテクチャのレイヤー整合性のチェック、依存方向の検証、レイヤード/オニオン/ヘキサゴナル/クリーンアーキテクチャへの準拠確認をユーザーが求めたときに、このエージェントを使用する。 ドメイン層やインフラ層に重要な変更があった後にも、プロアクティブに起動する。例: <example> Context: ユーザーがアーキテクチャが DDD のレイヤールールに従っているか検証したい user: "アーキテクチャの整合性をチェックして" assistant: "architecture-checker エージェントを使って、レイヤー間の依存方向と整合性を検証する。" <commentary> ユーザーは明示的にアーキテクチャ検証を要求している。architecture-checker を起動してレイヤー依存を分析する。 </commentary> </example> <example> Context: ユーザーがドメイン層のコードをリファクタリングした user: "ドメイン層をリファクタリングした。依存関係が壊れていないか確認したい" assistant: "architecture-checker エージェントでリファクタリング後の依存方向を検証する。" <commentary> ドメイン層の変更後に、依存違反がないかプロアクティブにチェックする。 </commentary> </example> <example> Context: ユーザーが新しいプロジェクトをオニオンアーキテクチャで構築している user: "オニオンアーキテクチャで実装しているが、レイヤー違反がないか見てほしい" assistant: "architecture-checker エージェントでオニオンアーキテクチャの整合性を検証する。" <commentary> 特定のアーキテクチャパターンに言及している。オニオンアーキテクチャのルールに対する検証を起動する。 </commentary> </example>

DDD 準拠レビュー、コードが DDD の原則に従っているかの確認、ドメインモデルの品質へのフィードバックをユーザーが求めたときに、このエージェントを使用する。 常にエキスパートレベルの厳格なレビュー基準を適用する。例: <example> Context: ユーザーがドメインモデルの DDD 準拠チェックを求めている user: "このドメインモデルがDDDに準拠しているかレビューして" assistant: "ddd-reviewer エージェントでDDD準拠度を厳密にレビューする。" <commentary> 明示的な DDD レビューの要求。包括的な準拠チェックのために ddd-reviewer を起動する。 </commentary> </example> <example> Context: ユーザーが新しい集約を実装し、フィードバックを求めている user: "新しく作った集約のコードを見てほしい" assistant: "ddd-reviewer エージェントで集約の設計品質をレビューする。" <commentary> 新しい集約のコードのレビューが必要。DDD パターンを検証するために ddd-reviewer を起動する。 </commentary> </example> <example> Context: ユーザーが DDD に正しく従えているか確信が持てない user: "DDDのベストプラクティスに沿っているか確認したい" assistant: "ddd-reviewer エージェントでベストプラクティスへの準拠度を検証する。" <commentary> ユーザーはベストプラクティスの検証を求めている。エキスパートレベルの評価のために ddd-reviewer を起動する。 </commentary> </example>

ドメイン設計の進化可能性・拡張性・保守性の評価をユーザーが求めたときに、このエージェントを使用する。 将来の変更にどれだけ適応できる設計になっているかを評価する。例: <example> Context: ユーザーが今の設計で将来の要求に対応できるか評価したい user: "この設計の進化可能性を評価して" assistant: "evolvability-assessor エージェントで設計の進化可能性を多角的に評価する。" <commentary> 明示的な進化可能性の評価要求。複数の軸で設計品質を評価するために起動する。 </commentary> </example> <example> Context: 大きな機能追加の前に保守性を懸念している user: "新機能を追加する前に、今の設計が拡張に耐えられるか見てほしい" assistant: "evolvability-assessor エージェントで拡張性を評価する。" <commentary> 機能追加前の評価。拡張への備えを評価するために起動する。 </commentary> </example> <example> Context: ユーザーが設計が SOLID 原則に従っているか検証したい user: "SOLID原則に従っているか評価してほしい" assistant: "evolvability-assessor エージェントでSOLID準拠度を含む進化可能性を評価する。" <commentary> SOLID 評価の要求。SOLID を評価軸に含む evolvability-assessor を起動する。 </commentary> </example>

ドメインイベントの特定・設計と対話的なイベントストーミングのファシリテーションを行う。 次のような依頼があったときに使う:「ドメインイベントを抽出する」 「イベントストーミングをする」「ドメインイベントを設計する」「イベントを洗い出す」 「domain eventを定義する」「イベント駆動にする」「イベント設計をレビューする」 「イベントの粒度を見直す」。 または、ドメインイベント、イベントストーミング、event storming、イベント駆動に言及する場合にも使う。

ドメインサービスの設計と、ロジックをエンティティ・Value Object・ドメインサービスのどこに置くかの判断を支援する。 次のような依頼があったときに使う:「ドメインサービスを設計する」「domain serviceを作る」 「このロジックをエンティティに置けないか検討する」「複数の集約にまたがるロジックをどうするか」 「サービスクラスを整理する」「ドメインサービスをレビューする」「重複チェックをどこに置くか」。 または、ドメインサービス、domain service、複数集約にまたがるルール、ドメインポリシーに言及する場合にも使う。

既存コードを DDD へ段階的にリファクタリングする戦略立案と実行を支援する。 次のような依頼があったときに使う:「DDDにリファクタリングする」「レガシーコードをDDD化する」 「貧血ドメインモデルを改善する」「トランザクションスクリプトから脱却する」 「段階的にDDDを導入する」「ドメインモデルを豊かにする」「アンチパターンを修正する」 「ドメインロジックをエンティティに移動する」。 または、DDD移行、貧血ドメインモデルの解消、Strangler Fig、段階的リファクタリングに言及する場合にも使う。

コードの変更差分・PR・指定ファイルを DDD 観点でレビューするワークフローを実行する。 次のような依頼があったときに使う:「DDD観点でレビューする」「DDDレビューをする」 「この変更をDDDの観点で見る」「PRをDDDでレビューする」「コミット前にDDDチェックをする」 「ドメインモデルの変更をレビューする」「diffをDDD観点で確認する」。 または、DDDレビュー、DDD観点のコードレビュー、ドメインモデルのレビューに言及する場合にも使う。

コードやロジックがドメイン層に属するかアプリケーション層に属するかを判定する。 次のような依頼があったときに使う:「このロジックはドメインか」「ドメインに置くべきか」 「ドメイン層かアプリケーション層か判定する」「ロジックの配置先を決める」 「このコードはどの層に属するか」「ユースケースかドメインか」 「ロジックの配置をレビューする」「レイヤー間の責務を分析する」。 または、ロジックの配置、ドメイン層、アプリケーション層、レイヤーの責務、ドメインロジックの判定に言及する場合にも使う。