Software Architect · 模块 19
只有当团队理解了这个决策、接受了它的代价，并且能在没有持续监督的情况下行动，架构才真正落地。
Stakeholders · facilitation · vocabulary · diagrams
架构师必须用听众的语言说话，但不能把含义压扁成空洞的口号。
不同的人需要不同的解释
同一条路线，司机、乘客和修理工会用三种方式描述。三种描述都可能是对的。
工程师需要 boundaries、contracts、edge cases 和 migration plan。Product manager 想知道对 roadmap 的影响、风险和 sequencing。业务关心的是 cost、time-to-market、compliance、reliability 和 future optionality。
差的架构师对所有人用一套话术，然后抱怨别人没听懂。好的架构师保留技术上的精确度，只调整抽象层级。
架构师在做 decision facilitation
好的主持人不是赢下争论的那个人。他帮助一组人看清选项、风险，并选出方向。
架构师的沟通不是一场"我的方案是对的"的演讲。它是一个过程：陈述 problem statement、收集 constraints、列出 options、对比 trade-offs、记录 decision 与 consequences。
当人们理解为什么某个替代方案被否决，阻力通常会下降——哪怕决策本身并不讨喜。
专业的沟通让 compromise 变得可见、可被检验。
例子：解释为什么暂不上微服务
有时候加快工程进度的方式，不是再加一个施工队，而是去掉多余的审批环节。
架构师说："接下来两个季度我们继续用 modular monolith。原因：一个团队、统一的发布节奏、负载不高、服务没有独立的 ownership。我们会引入 module boundaries 和 ADR。出现独立的 billing 团队或独立的 compliance 发布时，重新审视这个决定。"
这不是"微服务不好"。这是一个带上下文、带触发条件的 decision。
反例：靠权威压人
"我是架构师，就得这么干"——这句话能终结对话，但不会创造理解。
架构师强推 Kafka，理由是"这是 enterprise standard"，不解释问题、代价和替代方案。团队表面同意，但没理解模型，开始犯错，并慢慢绕开这个决策。
在架构里，权威而无清晰几乎一定会催生暗中抵触。
- 我要怎么把这个决策分别讲给工程师、PM 和 CEO 听？ - 哪些替代方案被认真考虑过？ - consequences 写在哪里？ - 这次谈话之后，团队能自己决定哪些事？