前言

卓越的软件架构师从何而来?

所有程序员都有成为架构师的潜力，只要掌握了架构师的思维方式和工作方法，你也能成长为架构师。

本文教你如何像架构师那样思考问题、理解需求、设计架构、评估结果、编写文档。本文不但通过真实案例讲解架构设计流程和经验，还总结了丰富的架构师工作原则和技巧，尤其适合广大程序员进阶学习。同时也适合产品经理、测试人员、运维人员和其他行业从业者深入理解软件架构设计工作。本文将给广大程序员的帮助：

• 成为出色的技术领导者

• 在快速迭代的敏捷开发中开展架构设计

• 避免项目波动和返工

• 带领团队共同成长

接下来就带大家一步步来学习本文具体内容讲解，希望本文能够得到大家的喜欢，多多转发+关注！

目录

主要内容

本文分为三部分。第一部分与第二部分建议从头至尾通读，第三部分则便于参考和检索。

第一部分介绍软件架构的基础知识和架构师必备的设计思维。第 1 章成为软件架构师;除了编程，架构师还有其他职责。他们要从工程角度定义问题。他们要将软件系统分解成多个可实现的模块，同时又要兼顾大局、确保系统整体有效工作。他们要在软件质量属性(quality attributes，是软件的非功能性需求)之间进行权衡，并管控不可避免的技术债务。更重要的是，他们要锻炼和提升整个团队的架构设计能力，因为最好的团队里人人都应该是架构师。

本章讲解架构师要做些什么。你将明白为什么理解软件架构可以让你成为更优秀的程序员和技术领导者。我还会介绍如何开始架构师的职业生涯。

第 2 章设计思维基础;无论是从头设计架构，还是改善已有的软件系统，我们需要的架构其实就在那里，等待我们去发现（ to be discovered，TBD）。架构设计总是一边摸索要解决的问题，一边探求解决方案。

为了完成这项任务，你需要学习一种分析和解决问题的创新方法，即以人为本的设计思维。将注意力放在受设计决策影响的人身上，可以帮助你理清必须解决的问题。这种设计思维强调我们的目标是打造帮助他人的软件，唯其如此我们的方案才能落地。

本章讲解如何在架构设计中运用设计思维。我们首先介绍设计思维的四条基本原则，然后学习用思维模式确保架构设计朝着正确的方向前进。最后，学习挑选合适的思维模式。

第二部分讲解架构师需要掌握的核心技能和知识。第 3 章制定设计策略;架构设计很容易陷入混乱无序的状态。哪怕软件系统充满了各种不确定性，我们也必须制订计划。凡事预则立，只有凭借稳固的设计策略，才能应付各种不确定性。

设计思维擅长为复杂问题寻找解决方案，它不是一蹴而就地解决问题，而是强调学习和实验的重要性。有人认为检验架构要先将其实现，但我们的做法是在设计过程中逐步验证架构的各个部分，同时运用思维模式和 TDC 循环确定下一步做什么。

第 2 章讲解了设计思维的基本原则和用法。本章将继续学习如何根据系统风险选择思维模式，并将其作为设计策略的一部分。

第 4 章换位思考;搞清楚到底要解决什么问题，往往是说起来容易做起来难。我们开发软件是为了服务于人，因此必须理解受软件影响的人。只有理解他们的需求，才能搞清楚到底要解决什么问题。

我们把与软件有关、受软件影响的人称为利益相关方（者)。架构师有责任确定利益相关方并了解他们的需求。利益相关方对系统的期望将直接或间接影响我们的设计方式。

换位思考( empathy，也叫同理心）是推动设计的引擎。只有站在利益相关方的角度思考和处理问题，才能开发出更好的软件。本章将学习在开始设计架构之前，如何决定与谁讨论你要解决的问题,以及你要从他们身上了解什么。

第 5 章挖掘关键架构需求;关键架构需求(architecturally significant requirement，ASR)是显著影响架构中的结构选择的需求。架构师有责任确定对架构有重大影响的需求。ASR 通常分为四类。

约束:给定或选定的不可更改的设计决策。

质量属性:外部可见特性，表征系统在特定环境下的运行情况。影响较大的功能需求:架构设计需要特别注意的特性和功能。

其他影响因素︰时间、知识、经验、技术、办公室政治、你的技术特长，以及其他影响决策的东西。

让我们仔细研究一下这四类 ASR，学习如何与利益相关方合作定义它们。

第 6 章主动选择架构;所有软件系统都有架构，但这并不意味着理想的架构会自动送上门来。如果你把设计决策交给命运，没人知道命运会带来什么结果。积极主动地思考和选择才能提高成功的机会。

架构设计就是在不确定的情况下做决策。决策就是做取舍，我们不得不做一些妥协——放弃一些东西以避免更坏的情况发生，或者接受不好的条件以便在其他方面做得更出色。只要做出合适的取舍，就可以实现关键架构需求，帮助利益相关方完成业务目标。本章学习运用关键架构需求制定决策，选择架构的结构。

第 7 章架构模式;数百年来，人们一直在提炼解决常见问题的方案，总结可复用的模式。软件工程继承了这一传统。经验丰富的架构师熟悉许多架构模式，面对新问题，他们会先回顾自己知道的模式，寻找合适的方案。确定架构模式后再根据实际情况做进一步的调整，以满足特殊的需求。

所有软件系统都有自己的核心模式，其他设计决策都以此核心模式为基础。使用模式相当于汲取前人的智慧,可以大大节省工作量。

已知的架构模式数量成百上千，覆盖各个领域。本章介绍最常见的架构模式，讲解如何让这些通用模式适应具体需求。

第 8 章建立模型，化繁为简;再成功的软件系统也难免走向复杂。用户数量的增加将给系统的可用性、可伸缩性、性能表现施加前所未有的压力。新功能不断插入，补丁越来越多，让软件越来越笨重。扩展系统的任务可能压得开发团队喘不过气。如果不保持警惕，软件系统最终会成为其自身成功的受害者。

当然，复杂性刚刚露出狰狞面目时，我们还是有办法控制的，比如通过需求变更和代码裁剪精简系统，将大件拆分成容易分析和管理的小件，还可以从细节中抽身出来，从更抽象的层面重新思考软件。

我们曾说过，架构是由结构组成的，而结构又是由元素和关系组成的。本章将学习使用这些基本构件创建有意义的模型，帮助我们分析、构思、推演我们的设计。

第 9 章召开架构设计研讨会;本章学习筹划和主持架构设计研讨会。读者将学习如何主持设计研讨会。良好的主持不仅仅是举止得当，更要让讨论顺利开展。本章讲解的方法将有助于提高研讨会的效率。

第 10 章展示设计决策;分享设计想法的最佳方式是把它展示出来。光凭嘴说，别人可能很难理解你的思路。把架构画出来，大家就能按照自己的节奏和方式来琢磨。开发人员都清楚，讨论抽象想法最好找一块白板，画点草图。把想法画出来才能保证大家的理解是一致的。

架构图没必要画得很精致，只要能够有效表达想法就行。第 8 章曾讲解过通过创建准确的模型来推演架构，提升质量属性。本章将学习绘制架构图，以便与开发人员沟通。

第 11 章描述架构;大家都不喜欢写架构文档，它占据了写代码的时间，而且看起来总是过时的。另外，文档格式常常很怪，编辑起来很麻烦。最重要的是，没有人愿意读!难怪有人说软件架构描述（缩写 SAD)是一个悲剧。

糟糕的架构描述着实让人难受，但出色的架构描述却能向团队展示清晰的愿景。优秀的架构描述是有用的资产，它能促进沟通与协作，将设计决策和思想有效传递给每一个人，提高软件开发的质量。

本章学习描述软件架构，用人性化的、简洁的形式向受众展示确切的信息，让大家爱上它。爱是一个带有强烈情绪的词，但我保证让人们爱上架构描述比你想象的简单。

第 12 章架构评估;对学生、家长、老师来说，成绩单是重要的反馈渠道。学生不必等到年底才知道自己的课程是“过了”还是“挂了”——通过每个季度的成绩单，就能判断自己是否获得了理想的成绩，以及哪些地方需要改进。架构评估的作用就像成绩单一样，它让我们尽早发现问题，从而按计划交付系统。

架构评估可以提高开发效率，而不是单纯地占用编程时间。顺利的话，架构评估一小时就可以完成，它很容易融入现有开发流程中，而且不需要团队成员掌握什么新知识。

本章将学习对架构进行评估。评估结果可用于指导团队、为设计决策提供支持、降低交付风险、提高架构设计水平。

第 13 章鼓励团队参与架构设计;开发现代软件系统需要借助团队的力量。科技进步（容器技术、云设施等）赋予了开发者更大的灵活性和权力。随之而来的新架构模式(微服务、FaaS 等)则对开发人员提出了更高的要求。他们必须清楚自己的决策会对包括质量属性在内的系统特性造成什么样的影响。

在现代软件开发中，开发人员与架构师的角色几乎没有差别。这并不是说现代软件开发团队不需要架构师，而是说我们需要的不再是那种传统的、居高临下的技术领导者。

今天的架构师应该与团队一起设计架构，而不是独自为团队设计架构。架构师应该既是技术专家，也是教练和导师。本书前两部分讲解了架构设计的核心原则和方法。现在，你要学习让团队与你一起成长，共同设计出色的软件架构。

第三部分讨论一系列实用的架构设计方法。世上没有万能钥匙，每位软件工程师都有自己的一套经验、方法、技术。第三部分将介绍我自己的经验、方法、技术。第 14 章理解问题的常用方法;理解模式要求我们主动从利益相关方处获取信息，用于定义(或重新定义)问题。不仅要理解需求，还要理解谁是利益相关方主体、理解系统的业务目标，同时开始构思如何设计架构满足需求。

第 5 章曾提到四类关键架构需求.这几类需求都会对架构产生影响，而质量属性的影响最大，是架构中的关键问题.

约束给定或选定的不可更改的设计决策。

质量属性外部可见特性，表征系统在特定环境下的运行情况。影响较大的功能需求架构设计需要特别注意的特性和功能。

其他影响因素时间、知识、经验、技术、办公室政治、你的技术特长，以及其他影响决策的东西.

本章介绍的方法能够让开发团队与利益相关方相互理解，从而挖掘出关键架构需求。如果你需要更好地理解问题，不妨试试这些方法。

第 15 章探索解决方案的常用方法;探索模式可以帮助我们发现各种解决问题的设计理念与工程方法。架构探索关注的是受架构控制的部分─—软件。我们并不是总有机会选择解决什么问题，但至少可以选择怎么解决。解决方案只受我们的知识、创造力、技能的约束。

探索似乎是没有边界的，但设计总是在前人的基础上开展的，设计思维的四条原则之一是善于借鉴（见第 2.1 节)。所有设计都是在已有设计基础上的重新设计和调整创新，探索首先要从这些已知的设计开始(比如第 7 章介绍的架构模式)。

架构师不仅是设计师，也是工程师，所以我们还要探索另外一些领域。比如软件的构建方法、已有的框架、经验法则，它们也会对架构产生影响;还有问题领域的概念和知识，这些是构思解决方案的出发点。当然，还要探索架构元素的关系和功能。

本章介绍的方法将帮助你构思各种架构设计方案。从这些方案中选择合适的架构，并找到相应的开发方法。

第 16 章展示设计的常用方法;介绍架构光靠嘴巴讲是不够的，应该设法展示出来。展示模式把抽象的想法(如设计概念)转变成可感知的对象，方便分享。将设计展示出来不但可以促进交流，而且可以用来检查设计能在多大程度上满足需求。设法展示的过程也是推演架构的过程。即使只是制作设计草稿，也是一种有用的思维练习。

除了画线框图，还有许多方式展示架构设计，比如制作原型、编写文档、开展实验、比较数据、讲故事，甚至表演。这些都可以用来向他人展示架构设计，而且效果都比单纯的语言交流更好。

本章介绍的方法将帮助你展示架构设计。你可以按照这里介绍的方法自己动手，但我建议你与他人一起合作，那样会更有趣，效果更好。这些方法的耗时一般不会超过 30 分钟。

展示的目的是分享，所以要请团队成员（或利益相关方）评估你制作的展示物。他们应该知道你希望展示什么样的想法。评估也是检查你对问题的理解是否与架构设计一致的过程。第 17 章将介绍常用的评估方法。

第 17 章评估设计方案的常用方法;评估模式帮助我们检查设计决策，确定它们满足需求的程度。设计不必追求完美，但至少应该够用。我们的目标是找到够用的架构，满足需求。解决方案只要够用就是合适和恰当的。

评估可以帮助我们发现不够用的架构部分。我们也许会发现自己对细节的理解还不充分。也许看起来不错的设计却有着不可接受的弊端(忽略了重要的约束，或者引入了过多的风险)。这种事知道得越早越好。越往后，修改决策的代价就越高。

评估结束后，我们应该有充足的信息来决定下一步采用哪种思维模式。TDC 循环（见第 2.3 节)的检查阶段当然需要用到评估模式，思考阶段同样也需要。

评估应该是一项持续开展的活动。等到设计结束时才做评估，很可能为时已晚。因此每一步工作都应该做评估。这样，只要我们认为某个部分的架构设计是恰当和合适的，就可以进一步完善它的细节。架构的所有部分在开始构建之前都应该准备充分。

本章介绍的方法可以帮助团队深入了解架构，收集采取行动所需的信息。这些方法既可以用来验证假设、选择设计方案，也能帮助你决定下一步要做什么。

这份【架构师修炼之道】总共有 313 页，如果需要完整版的小伙伴，可以：

1、点赞+收藏+转发此文，让更多人受益；2、关注小编，之后分享更新干货好文；3、**点击这里，获得文档领取方式**

本文的目标读者

本文是写给所有曾站在白板前画方框和线条，试图解决棘手问题的人看的。如果你是软件架构设计新手，本文很适合入门学习。我们将从介绍基础知识开始，由浅入深逐步讲解优秀软件架构师必须掌握的核心技能。

如果你是对架构设计略知一二的程序员，本文将有助于你整理思路。你会读到那些你既陌生又熟悉的概念，填补你自己都未曾意识到的知识空白。读完本文，你将更加深入地理解架构师的工作，以便日后更好地领导他人。

如果你是久经沙场的软件架构师，本文将教你从一个全新的视角来审视如何领导团队。今天，越来越多的初级程序员希望在软件开发中发挥更大的作用。文中讲解的基础知识将帮助你引导他们全面地参与到设计过程中来。

本文阐述的协作设计方法可以让你安全高效地与经验不足的团队成员进行合作。

希望本文能够帮助到大家的学习，让大家快速成长为架构师，也希望本文能够得到大家的喜欢！！