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、集約の分割、真の不変条件
error-classification
ソフトウェアにおける非正常状態(Error, Defect, Fault, Failure)の分類と定義を提供する。 JIS規格・JSTQB・Bertrand Meyer等の複数の標準に基づき、各概念の違いを明確化し、 適切なエラー設計・障害対策の判断を支援する。エラー設計、障害分析、コードレビュー、 テスト設計時に用語の混乱を防ぎ、正確な分類に基づく対処戦略の選択に使用。 対象言語: 言語非依存。 トリガー:「ErrorとFaultの違い」「DefectとBugの関係」「障害と故障の区別」 「エラーの分類」「Failureとは何か」「非正常状態の設計」「エラー用語の定義」 「エラーと欠陥の違い」「faultとfailureの違い」 といったエラー分類・用語定義関連リクエストで起動。
インストール方法を見る含まれるファイル(1)
- SKILL.md7.1 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Error, Defect, Fault, Failure 分類ガイド
ソフトウェアの非正常状態を正確に分類し、適切な対処戦略を導く。
なぜ分類が重要か
Error, Defect, Fault, Failure は混同されやすいが、それぞれ異なる概念であり、対処戦略も異なる。用語を曖昧に使うと、設計判断を誤る原因となる。
規格別定義の比較
| 種別 | Error(エラー) | Defect(欠陥) | Fault(障害) | Failure(故障) |
|---|---|---|---|---|
| JIS X 0014:1999 | 値または状態の不一致(人的過誤を含まない) | - | 機能単位の能力の縮退・喪失を引き起こす異常な状態 | 要求された機能を遂行する機能単位の能力がなくなること |
| JIS Z 8115:2000 | 値または条件の不一致(人的過誤を含む) | - | 機能を遂行不可能なアイテムの状態 | アイテムが要求機能達成能力を失うこと |
| JSTQB | 間違った結果を生み出す人間の行為 | 機能が実現できない原因となる不備(Bug含む) | 欠陥(Defect)と同義 | 期待した機能から逸脱すること |
| Bertrand Meyer | 開発中になされた誤った決定 | 意図した振る舞いからシステムが逸れる原因となる特性 | 実行中に意図した振る舞いから逸れるイベント | - |
| JIS Q 9000:2006 | - | 意図された用途に関連する要求事項を満たしていないこと | - | - |
実用的な解釈
Error(エラー)
入力値と期待値の相違状態。
- バリデーションエラー(入力値が期待する範囲外)
- ファイルが存在しないなどリカバリ可能な想定内の事象
- 呼び出し元が対処可能
例: ユーザー入力のメールアドレス形式不正、存在しないリソースへのアクセス
対処: Either/Result型で表現し、呼び出し元に判断を委ねる
Defect(欠陥)
要求事項を満たしていない状態。バグを含む。本来発生してはいけないもの。
- 契約(Design by Contract)の不履行
- 呼び出し元が事前条件を満たしていない
- アサーション(表明)で対応すべき
例: null不可の引数にnullが渡された、不正な状態遷移の試行
対処: アサーション(require/assert)で即座に検出・停止
Fault(障害)
機能遂行不可の異常状態。リカバリ不能。
- 呼び出し先のバグまたは責任不明
- システムの異常状態
- Akka/ErlangではError KernelとLet it crashパターンで耐性を持てる
例: DBコネクション枯渇、メモリ不足、外部サービスの完全停止
対処: 障害の隔離(Error Kernel)、監視と再起動(Let it crash)
Failure(故障)
機能達成能力を失った状態。
- Faultが解消されない結果としてシステムが機能を提供できなくなる
- ユーザーから見た最終的な症状
例: サービス全体のダウン、レスポンス不能
対処: 冗長化、フェイルオーバー、サーキットブレーカー
因果関係
Error(エラー)
→ 想定内。呼び出し元で対処可能
Defect(欠陥)
→ 本来あってはならない。アサーションで検出
→ 修正されなければ Fault を引き起こす
Fault(障害)
→ 異常状態。リカバリ困難
→ 継続すると Failure に至る
Failure(故障)
→ 機能喪失。ユーザーに影響
設計への適用
分類に基づく対処戦略
| 分類 | 対処戦略 | 実装パターン |
|---|---|---|
| Error | 呼び出し元で対処 | Either/Result型、バリデーション |
| Defect | 即座に検出・停止 | アサーション(require/assert)、事前条件チェック |
| Fault | 隔離と回復 | Error Kernel、Let it crash、サーキットブレーカー |
| Failure | 予防と冗長化 | フェイルオーバー、冗長構成、監視・アラート |
判断フロー
非正常状態が発生
↓
呼び出し元で想定・対処可能か?
├─ YES → Error(エラー)
│ → Either/Result型で表現
└─ NO ↓
本来発生してはいけない状態か?(契約違反)
├─ YES → Defect(欠陥)
│ → アサーションで即座に停止
└─ NO ↓
機能が遂行不可能な異常状態か?
├─ YES → Fault(障害)
│ → 隔離・監視・再起動
└─ 機能達成能力を喪失
→ Failure(故障)
→ フェイルオーバー・冗長化
error-handling スキルとの関係
本スキルは非正常状態の分類と概念定義を扱う。具体的な実装パターン(Either/Result型の使い方、言語別ライブラリ等)は error-handling スキルを参照。
| 観点 | 本スキル | error-handling スキル |
|---|---|---|
| 焦点 | 概念の分類・定義 | 実装パターン |
| 対象 | Error/Defect/Fault/Failure全体 | 主にErrorの処理 |
| 用途 | 設計判断・用語統一 | コーディング・レビュー |
レビューチェックリスト
- エラーハンドリングコード内で、Error/Defect/Fault/Failureが適切に区別されているか
- 想定内のError(バリデーション等)をResult型で表現しているか
- Defect(契約違反)をアサーションで検出しているか
- ErrorとDefectを混同して同じハンドリングをしていないか
- Faultに対する隔離・回復戦略が存在するか
- 例外を「何でもcatch」して、Defectを握り潰していないか
関連スキル(併読推奨)
このスキルを使用する際は、以下のスキルも併せて参照すること:
error-handling: 分類に基づくエラー処理の実装パターン(Either/Result, 例外等)aggregate-design: 集約操作における不変条件違反とドメインエラーの区別domain-building-blocks: 値オブジェクト構築時のエラー分類
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(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はインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。
CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。