软件架构设计指南

要解决什么问题

架构评审里最常见的争论不是“哪个技术更先进”，而是缺少统一的判断依据：项目应该上微服务还是先做单体？事件驱动能解耦多少真实收益？Serverless 的运维边界划在哪里？质量属性之间互相冲突时，该牺牲可扩展性还是可观测性？这些问题如果没有结构化方法，很容易变成个人经验主导的拍脑袋决策。本技能把架构设计从“灵感驱动”拉回“需求驱动”，让模式选型有可复用的检查清单和权衡路径。

核心能力与工作方式

技能的核心方法围绕四个维度展开：需求驱动按体量、团队规模、演进速度定架构；模式选型覆盖 单体、微服务、事件驱动、Serverless 的权衡；质量属性评估 可用性、扩展性、安全性、可观测性；设计表达用 C4 分层图 与 时序图 把设计意图说清楚。

实际使用时按四个步骤推进：

1. 明确目标与场景边界，先界定系统要服务的业务边界和约束条件。
2. 逐项执行或自查，按需求、模式、质量属性、表达四层方法检查当前设计。
3. 输出结构化结果，生成清单、分级或建议，而不是一段模糊结论。
4. 标注不确定项，把需要人工复核的环节单独列出，避免把假设当成事实。

适用边界与注意点

适合在架构设计、architecture 评审、微服务/单体拆分、质量属性权衡、C4 图表达等场景提供方法论参考和清单支撑。不适合需要实时数据或外部系统直连的高频自动化任务，也不提供法律、医疗、财税等需要持牌专业人士出具的确定性结论。

需要特别留意的是，架构没有银弹，任何模式都有隐含成本。避免脱离团队实际能力做“过早优化”，尤其是为了未来可能的规模而提前引入微服务治理体系。所有建议都应结合当前工程能力、组织结构和交付节奏做二次判断。