architecture-lens

Architecture Lens

Richards と Ford の Fundamentals of Software Architecture および Practical Model-Driven Enterprise Architecture を用いて、コードレベルの構造をレビューします。結合度、配置、凝集度、依存関係の方向、スコープを通じて、変更のしやすさを評価します。実際の選択にはトレードオフがあります。すでに決定済みの事項に対して、別の選択肢を無理に作り出すことなく、そのコストを明示してください。

システムスタイルには macro-architecture、ドメインモデリングには domain-driven-design、正確性またはセキュリティのレビューには full-review を使用してください。

レンズを選択する

決定またはレビュー	読み込む手法
未解決のアプローチ、境界、ライブラリ、同期／非同期、または構築／再利用の選択	レンズ 1：references/decision-review.md
複雑に絡み合ったコード、または分割、抽出、統合する対象の決定	レンズ 2：references/coupling-review.md
差分や設計におけるレイヤーの配置、凝集度、依存関係の方向、またはスコープ	レンズ 3～6：references/structural-review.md

質問で必要な場合に限り、手法を組み合わせてください。影響を受けるコードとその契約を調べてください。局所的な境界のレビューに、リポジトリ全体の把握は必要ありません。既存の設計上の決定と根拠を活用してください。

Connascence では、結合度を強度 × 局所性 × 範囲で評価します。強い結合でも局所的であれば許容できる場合があります。一方、離れた場所にある動的な結合には注意が必要です。最小限で一貫性のある形を保ってください。変更に必要な範囲を超える間接化を持ち込まず、推測的なスコープを取り除いてください。

権限と出力

このスキルは指摘事項を報告します。スコープを限定した修正をユーザーが依頼した場合は、その編集が許可されます。design-gate またはその他の読み取り専用レビューの呼び出しでは指摘事項のみを返し、単独での編集ルートより優先されます。

単独レビューでは、選択したレンズごとに指摘事項をまとめ、file:line、違反しているルール、具体的な修正方法を示してください。決定に関する報告では、選択した形、実際のトレードオフ、次の対応を記載してください。小さな決定なら、2 行でまとめてもかまいません。問題のないレンズの結果は clean としてください。分類を埋めるために、指摘事項や反対意見を作り出してはいけません。

design-gate の場合は、呼び出し元が定めた標準のゲート結果を使用してください。重要な問題は修正が必要となる場合がありますが、見た目上の好みはその理由になりません。

3 つすべてに該当する場合にのみ ADR を作成してください：元に戻しにくい、背景なしでは意外に感じられる、そして実際のトレードオフがある場合です。3 つすべてに該当する場合は、references/adr-template.md を使って決定時に記録してください。それ以外の場合は、既存のタスクまたはレビューメモに決定を残してください。

インタビューでは、決定、根拠、制約、参照元を既存の決定記録に追加してください。この段階では、単独レポートおよび実装の手順は適用されません。

追加リファレンス

• references/verification-menu.md：指摘事項に実行可能なチェックが必要な場合。
• references/fitness-functions.md：永続的なアーキテクチャルールを適用する必要がある場合。
• references/risk-and-diagrams.md：移行、可用性の境界、実績のない技術、または図の作成依頼にリスクモデルが必要な場合。

選択した手法から、詳細な分類体系とチェックリストを参照できます。決定に必要な場合にのみ、それらを読み込んでください。