软件架构师的主要职责是解决根本复杂性，避免引入偶发复杂性，通过有效沟通分析客户需求并推动项目开发。架构师必须重视具体情境、记录决策理由以及确保解决方案简单可用，注重业务目标与技术之间的桥梁。通过培养情景意识和适应变化来持续提升软件设计的灵活性和有效性。

1. 软件架构师应该知道的97件事
Daniel

2. 简化根本复杂性，消除偶发复杂性
◦ 根本复杂性指的是问题与生俱来的，无法避免的困难；
偶发复杂性是人们解决根本复杂性的过程中衍生的。
◦ 架构师的职责在于解决根本复杂性，同时避免引入偶发
复杂性。

3. 关键问题可能不是出在技术上
 大多数项目是由人完成的，人才是项目成败的与
否的基础
 关于对话的技巧非常多，但有几个简单的技巧可
以显著改善对话的效果：
◦ 不要把对话当成对抗。
◦ 不要带着情绪与人沟通
◦ 尝试通过沟通设定共同的目标。

4. 分析客户需求背后的意义
 架构师可以通过询问客户，分析客户要求的功能和需
求的真正意义，定位真正的问题，从而提出比客户的
建议更好，成本更低的解决方案。
 敏捷宣言提供了答案：“客户合作重于合同谈判”。
具体来说，架构师应该通过与客户面对面的交流，关
注客户的需求，引导客户回答“为什么”的问题。要
知道说明“为什么”并不容易，因为客户往往觉得问
题是不言而喻的。
 此外，避免与客户讨论技术上的具体实现，这样会喧
宾夺主，因为此时应该关注的是客户的问题，而不是
软件开发的问题

5. 起立发言
 架构师更需要与人打交道，无论是劝说开发人员
接受具体的设计模式，还是向管理层解释购买中
间件的利弊，沟通都是达成目标的核心技能。
 当你站立时，无形中增添了一种权威和自信，自
然就控制了场面，听众不会轻易打断你的发言。
 让沟通事半功倍，起立发言是最简单有效的方法。

6. 不存在放之四海而皆准的解决方案
 架构师应该坚持培养和训练“情景意识”——因
为我们遇到的问题千差万别，不存在放之四海而
皆准的解决方案。

7. 提前关注性能问题
 坚持，技术测试是需要耐心和毅力，无论是搭建
合适的测试环境，采集适当的数据集，还是编写
必要的测试用例，都需要投入大量的时间。提前
展开性能测试，能让你有条不紊地逐步完善测试
环境，为解决性能问题节省下大量的时间和精力。

8. 业务目标至上
 在商业化的背景下开发企业应用，架构师必须成为业
务部门和技术部门之间沟通的桥梁，周旋调解，兼顾
各方的利益，同时用业务目标来驱动项目开发。业务
目标和实际的开发条件应该成为架构师主持制定决策
的参照系统。
 架构师必须通过协调，即保护软件架构，又坚持业务
目标，即允许开发人员制定微观（技术决策），又设
法避免他们参与制定业务决策。如果技术决策脱离了
业务目标和现实条件的约束，则无异于用宝贵的稀缺
资源进行高风险的投机。
 用业务目标驱动项目开发，才能保证软件开发团队的
长远利益。

9. 先确保解决方案简单可用，再考虑通用性和
复用性
 多数开发这开发的是专用系统，无限制的通用性
对他们帮助不大。追求通用性最好的办法是研究
现有的具体案例，抓住问题的实质，从根本上得
出通用解决方案。通过经验提炼的简单方案，远
胜过不切实际的通用性。
 设计组件的首要任务是抓住具体需求，满足需求。
通用性来自对需求的理解，理解之后才能简化。
提炼通用性可以使我们更加接近问题的本质，通
过分析已有案例可以获得清晰、简洁、有依据的
规律和方法。

10. 重视不确定性
 面临两种选项时，多数人认为最重要的是从中选
择，然而设计（无论是软件设计还是其他设计）
并不是这样的。当你面对两种可能性是，应该仔
细考虑设计存在的不确定性。不确定性可以促使
你推迟决定，收集更多的信息；促使你用分隔和
抽象的方法来降低设计决策的重要性。
 如果出现两个合理的选择，架构师应该停下来，
设法找出介于两者之间的，具有更低重要性的决
策，而不是简单的在两者中作出选择。了解两者
之外还存在其他选择，比决策结果本身更有价值。

11. 让大家学会复用
 大家知道它们存在
 大家知道如何使用他们
 大家认识到利用已有资源好过自己动手

12. 学习软件专业的行话
 架构模式和设计模式分成四大类：企业架构模式、
应用架构模式、集成模式、设计模式。
 企业架构模式定义了架构的全局框架结构。常用
的模式包括事件驱动架构（EDA）、面向服务的
架构（SOA），面向资源的架构（ROA），还有
流水线架构。

13. 事物发展总会出人意料
 设计中的这些微小变化积累起来，很快就需要对
设计进行一次较大的变更。
 设计是一个不断发现的过程。在实现时，我们会
发现通常无法预知的新东西。设计是在不断变化
的世界中持续进行探索实验的过程，只有接受这
点，我们才能明白，设计过程也必须保持灵活性
和持续性。固守最初的设计，并迫使实现遵循最
初的设计，只能产生更为糟糕的结果。因此，要
理解一点，事物发展总会出人意料。

14. 具体情境决定一切
 具体情境决定一切，根据它设计精良简单的解决
方案。换句话说，架构决策只在情境需要时，才
能牺牲尽量简单的原则。

15. 避免重复
 两条公认的软件开发的真理：
◦ 复制是魔鬼
◦ 重复性的工作拖累开发进度
 复制的部分通常不属于领域逻辑，而是承担底层
工作的基础性代码。因此，架构师一定要警惕示
例可能会产生的影响。这些代码和配置将成为成
百上千个系统切片的模版，应该做到简洁、意图
明确，只包含无法抽取掉的，与领域问题相关的
内容。

16. 架构师当聚焦于边界和接口
 为了分离关注点，人们发明了封装的办法，从封
装又引出了边界和接口的概念。

17. 助力开发团队
 只要不违背软件设设计的总体目标，就让开发人
员自己做出决策。但是，不仅为了确保质量，也
为了能够对开发人员进行深度授权，我们要在数
量上设置限制。为了一致性，也为了减少麻烦和
无关紧要的决定（它们不是开发人员要解决的根
本性问题的构成部分），我们要创建一些标准。
创建一个清晰的路线图，向开发人员说明应当如
何放置源代码文件，如果对之命名，何时应当创
建新文件等诸如此类的问题。

18. 不要急于求解
 不要立即着手去解决面前的问题，而是要看看自己是
否可以改变问题。问问自己，如果没有这个问题，系
统架构会是怎么样的？这样的自问自答，可能最终帮
你找到更加优雅可行的解决方案。有时候业务问题确
实需要得到解决，但有时，或许并非那么迫在眉睫。
 由于架构师往往习惯迅速进入问题的解决模式，我们
常常忘记，或者根本就不知道如何是审视问题本身。
我们应该学会像长焦镜头一样，不断地拉近放远，以
确保正确的锁定问题，而不是一味的接受别人给出的
问题。在需求面前，我们不应该成为被动的储蓄罐，
像糖果盒一样时刻准备者掏出各种各样的聪明点子。

19. 优秀的软件不是构建出来的而是培育起来的
 无论多么诱人，都要抵制住试图设计出庞大完整的系
统，来“满足甚或超出”已知需求或者特性期望的想
法。要有宏伟的远景，但不要有庞大的设计。环境和
需求的变化不可避免，你和你的系统要学会适应变化。
 设计尽可能小的系统，帮助成功交付，并推动它向宏
伟的远景目标不断演化。虽然听起来似乎放弃了控制
权，甚至是在逃避责任，但最终，利益相关者会感谢
你。注意，不要把这种演化方法和削减需求、规范混
乱和生产废品这样的做饭混淆在一起。

20. 记录决策理由
 记录软件架构决策理由的文档，长期有用，又无须为之付出过
多的维护精力，具有很高的投资回报价值。
 这类文档迟早会派上用场，比方说：
◦ 可以作为和开发人员进行沟通的工具，说明应遵循的重要架构原则
◦ 当开发人员对架构背后的逻辑提出疑问时，使团队成员能够“就事论
事”，甚至能够避免一场“兵变”
◦ 向经理和利益相关者说明这样构建软件的确切原因（比如，采用某种
较为昂贵的硬件或软件的必要性等）。
◦ 把项目移交给下任架构师（你有多少次在接手软件时很疑惑原来的设
计者究竟为什么要采用那种做法？）。
◦ 逼着你明确说明出理由，有助于确保基础（fundation）是扎实稳固
的
◦ 如果相关条件发生变化，需要对决策进行重新评估，它可以作为一个
起点。