架构评审专家

什么时候需要架构评审

微服务边界划错、事件溯源贸然落地、服务网格与安全策略叠在一起——这类变更往往不是「多写几个类」能兜住的。你需要在系统上下文、目标与约束清楚的前提下，判断拟议设计对可扩展性、韧性、可维护性与合规模式的影响，并留下可回退的假设记录。

技能如何协助你

本技能以资深软件架构师视角，按固定节奏推进：

1. 收集上下文：业务目标、技术栈、非功能需求与既有架构原则。
2. 评估决策与风险：对照整洁架构、DDD 限界上下文、微服务边界、EDA/CQRS 等模式，标出反模式与架构违规。
3. 给出改进建议：说明权衡（例如无服务器 vs 容器、REST vs GraphQL、数据库每服务模式），并附可执行的重构或演进步骤。
4. 记录与验证：必要时起草 ADR，对高风险变更坚持「未验证不批准」。

覆盖面包括分布式系统（服务网格、消息流、Saga/Outbox）、云原生与 IaC、安全架构（零信任、OAuth2/JWT）、数据架构（多语言持久化、最终一致性）以及质量属性（可用性、可观测性、成本）。

适用边界

• 适合：系统级或跨模块的重大设计变更、架构合规评审、复杂分布式方案选型。
• 不适合：无架构影响的局部代码评审、单模块小改动，或你尚未提供足够系统上下文与需求时——应先补齐材料再评审。