软件架构师：
应明确提出假设或先决条件，从而防止隐性假设
知道隐性假设可能会导致利益相关方之间的潜在误解

---

1. 应明确提出假设或先决条件，防止隐性假设

为什么重要？

• 隐性假设是架构风险的温床
  例如：假设“所有服务都能在100ms内响应”，若未显式声明，可能导致：
  • 调用方未设计超时机制 → 级联故障
  • 运维团队未配置监控告警 → 故障无法快速发现
• 技术债务的源头
  如默认团队熟悉某框架（实际新人占比高），代码质量会因学习成本陡降。

实践方法

场景	显式化方法	案例
技术约束	在架构决策记录（ADR）中声明	“服务通信必须使用gRPC，因二进制协议性能比JSON高50%”
资源假设	在部署规范中标注	“数据库需SSD存储，IOPS≥5000”
第三方依赖	在上下文图中标记SLA	“支付网关可用性99.9%，超时需重试2次”
团队能力边界	在项目启动文档中说明	“前端团队需掌握Vue3，否则培训周期增加2周”

---

2. 知道隐性假设可能导致利益相关方误解

典型误解场景

破解策略

1. 术语统一词典
   创建《架构术语表》，例如：

   • “弹性伸缩”：指系统负载＞80%时自动扩容，响应延迟＜10s
   • “数据一致性”：指最终一致性，最大延迟60秒

2. 多视角验证

   • 用可执行原型验证性能假设（如模拟10K并发）
   • 通过架构工作坊让开发/测试/运维共同评审假设

3. 假设跟踪矩阵

   假设内容	影响范围	验证方式	失效应对方案
   “CDN延迟≤50ms”	全局用户体验	压测+监控	启用备用CDN供应商
   “消息队列无丢消息”	订单交易	混沌工程测试	补单机制+告警

---

架构师的核心行动清单

1. 挖掘隐性假设

   • 通过“5 Whys分析法”追问设计决策根源
     例：为什么选Redis？→ 因需要低延迟 → 延迟要求多少？→ ≤2ms → 是否验证过网络拓扑？

2. 可视化假设

   • 在C4模型或架构图中用红色注解标出高风险假设

3. 建立反馈环

   • 在CI/CD流水线中加入假设校验测试（如性能阈值检测）

关键洞察：优秀的架构师不是避免假设（这不可能），而是像科学家一样显式管理假设——将其转化为可验证、可追溯、可应对风险的公开约束条件。这直接决定了架构的适应性和系统可靠性。