specsfy-specialist-software-architecture

软件架构

适用场景

• 用于做出难以撤销的高成本决策：引入服务、队列、分布式缓存，更改模块边界或结构性依赖方向。
• 当质量属性（延迟、可用性、一致性、容量）需要成为明确的决策标准时，也应使用。
• 对不会影响边界的重命名、移动文件或局部重构，不要使用——这些属于维护，而不是架构决策。
• 如果争议中的边界属于尚未建模的领域概念，请先运行 $specsfy-specialist-domain-modeling——架构负责确定领域已定义的边界应放在哪里，而不是凭空创造边界。

流程

1. 明确系统的用途、实际约束（预算、期限、可用团队）和可量化的质量属性场景（不要使用“可扩展”等形容词）。
2. 梳理观察到的现状：数据所有者、模块／服务之间现有的依赖关系、关键运行时流程，以及当前问题所在。
3. 找出相互冲突的因素、之后难以撤销的决策，以及每种方案的风险。
4. 按相同标准（步骤 1 中的场景）比较选项，并考虑每种方案的实际运维成本——网络、分布式一致性、额外的可观测性、需要协调的团队。
5. 选择能够满足既定场景的最精简结构——默认选择满足质量属性的最简单方案。
6. 制定迁移计划：迁移期间的兼容性、用于检测回归的可观测性，以及切实可行的回滚路径。
7. 记录决策（ADR），并尽可能通过自动化依赖测试或静态分析验证拟定的边界。

模式

• 为每个模块定义明确的职责、数据和接口——没有明确契约的模块会给使用方带来隐式耦合。
• 让依赖从易变策略指向稳定策略（依赖规则）：业务模块不应依赖框架／基础设施细节；反向依赖才是健康的默认模式。
• 没有真实且可量化的使用场景作为依据时，不要引入服务、队列、缓存或抽象层——投机性抽象会带来永久成本，却只有假设性的收益。
• 明确区分已实现的架构（当前存在的内容）和目标架构（正在迁移的方向）——将两者视为同一回事会掩盖技术债和待办工作。
• 将每种质量属性表述为可量化的场景：刺激、环境、预期响应、度量指标（例如：“在 200 req/s 下，p99 < 300ms”），不要只用笼统的形容词。
• 将易于替换的决策保留为局部且可逆的选择，只有之后确实难以更改的决策才明确记录（ADR）。
• 通过可验证的渐进式切入点（strangler fig、expand/contract）逐步演进架构，而不是彻底重写——彻底重写很少能按期交付，还会丢失当前系统中积累的知识。

反模式

• 仅仅因为“这是行业标准”就采用微服务，却没有相应的规模、团队或独立部署场景作为依据——分布式一致性和运维复杂度增加所带来的成本真实且立刻发生；在场景出现之前，收益只是假设。
• 大泥球：模块没有明确的边界或依赖方向，任何部分都可以直接调用其他任何部分。
• 缺少可量化的质量场景却进行前期大规模设计——没有具体刺激作为依据的“面向未来”架构，往往会解决错误的问题，并过早锁定原本可逆的决策。
• 当目前只有一个真实使用方时，仅为了“未来的灵活性”就添加通用间接层——在有任何证据表明会用到灵活性之前，就先承担复杂性成本。

验证

• 已针对定义的场景评估关键路径、故障模式、一致性要求和容量，而不仅是正常路径。
• 存在架构或依赖测试（如果语言／工具支持），用于锁定已决定的依赖方向。
• 已演练迁移：验证过迁移期间的兼容性，也测试过回滚计划，而不只是描述计划。
• 安全、数据和运维影响已作为决策的一部分进行审查，而不是事后才考虑。
• 不得在没有可衡量场景和证明性证据的情况下，将架构称为“可扩展”或“有弹性”——没有证据的绝对化表述一律禁止。

相关 Skills

• $specsfy-specialist-technical-research：当决策取决于外部能力、限制或兼容性时，收集一手证据。
• $specsfy-specialist-domain-modeling：在决定服务／模块边界之前，确定领域概念的边界。
• $specsfy-specialist-delivery-engineering：制定架构迁移的发布和回滚计划。
• $specsfy-specialist-performance-engineering：当存在争议的质量属性是实际负载下的延迟或容量时使用。
• $specsfy-specialist-code-review：检查已实现的代码是否遵循此处确定的边界。

请阅读 references/standards.md，了解架构视图、ADR 格式、质量属性和一手资料来源。