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、违反的规则和具体修复方案。进行决策时，说明所选方案、实际取舍和下一步行动。小型决策可以用两行说明。若视角审查结果干净，则返回 clean；不要为了填满类别而编造发现或反方观点。

在 design-gate 下，使用调用方的规范门禁结果。关键问题可能要求修改；外观偏好则不能作为要求。

三项条件全部满足，或不写 ADR：难以撤销、没有背景时会令人意外，而且存在真实取舍。三项条件都满足时，决策确定后记录，使用 references/adr-template.md。否则，将决策保留在现有任务或审查记录中。

在面试中，将决策、理由、约束和来源引用补充到现有决策记录中。该阶段不适用独立报告和实现流程。

附加参考资料

• references/verification-menu.md：发现需要可执行检查时使用。
• references/fitness-functions.md：需要强制执行长期有效的架构规则时使用。
• references/risk-and-diagrams.md：迁移、可用性边界、未经验证的技术或用户要求的图示需要风险模型时使用。

选定的方法会链接到详细的分类体系和检查清单。仅在决策需要时加载这些内容。