《聊聊架构》结束前，要不要再听听它的故事？

《聊聊架构》近期将从极客商城下架。自去年在极客商城独家销售以来，《聊聊架构》已经陪伴大家 10 个月之久。从第一周销量就突破 3000 本到后续收到无数读者的书评，用户的每一点反馈我们都倍感珍惜。年后我们又加印了 1000 本，希望这本书最后能给您带来一些收获。

在软件行业，架构师和工程师就类似于上帝，创建出形形色色的软件产品来服务于人类。要想当好这个角色，架构师自然也需要具备某种上帝的视角，来观察并表达这个世界。

《聊聊架构》以作者的架构经验为基础，逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题，帮你理清技术、业务和架构之间的关系，洞见架构之道，进阶为更优秀的架构师。

什么是架构？

架构实际上解决的是人的问题，架构的产出物就是对问题的分析，以及解决问题的方案。它包括：拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

1. 根据要解决的问题，对目标系统的边界进行界定。

2. 对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。并对这些切分出来的部分，设立沟通机制。

3. 根据 2，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

这就是架构。

认识概念是理解架构的基础

要做好架构首先必须具备的能力是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题。

比如，什么是“杯子”？杯子这个概念并不是瓷器，回归作用：其实是为了解决“人需要一个可单手持握，但是希望避免直接接触所盛物体”这个问题。

每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。

事实上，这一能力，在任何一个领域都是适用的。比如我们如果想要学习一项新的技术，如 Hibernate、Spring、PhotoShop、WWW、Internet 等等，如果知道这些概念所要解决的问题，学习这些新的技术或者概念就会如虎添翼，快速的入手；学习一个新的领域，也会非常的快速有效；使用这些概念来解释问题，甚至发明新的概念都是很容易的事。

为什么强调这个？因为做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。

如何做好架构？

识别问题，找到问题的主体

如果把真正的问题找到，那么问题就已经解决了 80% 了。这个能力基本上就决定了架构师的水平。

找出问题的主体，是做架构的首要问题。这也是前面强调的，我们要解决的问题，一定都是人的问题。

更进一步，作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。

再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。

一般来说，从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。最坏情况就是当我们时间或者能力有限，实在是无法定位出是谁的问题的时候，比如系统出故障，也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响的范围。给我留出时间和空间去识别真正的问题。

总结一下，要正确的认识问题，需要问两个问题：

1. 这是谁的问题？

2. 有什么问题？

当得到的回答是支支吾吾的时候，我们就知道正确的方向在哪儿，以及需要做哪些事了。以我的经验，问题 1 会花比较多的时间，也是支支吾吾最多的地方，因为架构要解决的问题都是人的问题。但是一旦确定了答案，问题 2 就会变得非常容易。可以这样说，架构师的能力大部分会体现在问题 1 的识别上。

架构切分，本质上是利益的调整

在识别出是谁的问题之后，会发现，在大部分情况下，问题都迎刃而解，不需要做额外的动作。但总还有一部分确实是有问题的，需要做调整，那么就必须要有所动作，做相应的调整。

这个调整就是架构的切分。简单来说：

1. 架构的切分的导火索是人的负载太重。

2. 架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。

3. 架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。

4. 架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。

什么是软件？

软件的历史，实际上可以说是用机器模拟人的历史。不管大家有没有意识到，我们都有意无意的在计算机上模仿人类的行为。人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。

所以，软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。

随着软件的规模的变大，程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。

软件架构到底是要解决什么问题？

如前所述，软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题：

业务问题

具体的现实生活状态下，没有软件的时候，所解决的问题的主体是谁，解决的是什么问题，是如何解决，如何运作的？

计算机问题

如何把现实生活用软件来模拟？模拟出来的软件，需要哪些硬件设施才能够满足要求？ 并且当访问量越来越大的时候，软件能否支持硬件慢慢长大，性能线性扩展？因为硬件是可能会失效的，软件如何在硬件失效的情况下，仍然能够保证可用性，让用户能够不中断的访问软件提供的服务？怎么收集软件产生的数据，为下一阶段的工作提供依据？

总之，软件架构包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。

架构师没有话语权，还架什么构！

架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。

如果架构师只能够通过建立某些流程来行使架构师的权利，比如强制架构 review，反而会造成很多内部不必要的冲突，最终都会导致这些流程流于形式，得不偿失。

反过来，具备架构师能力的组织领导人，一定是一个很好的领导，这个组织一定是很健康向上的，因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感，会及时的调整组织架构，在问题发生之前就解决了。

这样这个组织就会具备更好的抗压能力，能够更好的为这个组织的客户服务，这个组织的成员内心一定都是比较平衡的，每个人的能力都能够得到比较好的发展。

所有架构的核心就是组织架构。或者也可以这样说，一个合格的组织领导人，一定必须是一个合格的架构师。

从架构的角度看如何写好代码

我们经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。

工程师要想真正快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关 stakeholder 的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。

这里还有作者分析的案例和图示，请看书细细品味吧。

所以，你理清技术、业务和架构之间的关系了吗？

技术人普遍看不起业务，认为技术更高端，而业务太低端，并且业务往往喜欢给技术挖坑。业务则觉得技术眼光高却实际解决不了问题，而且常常理解有偏差，但是业务又无可奈何，因为自己不会。

为什么会发生这种冲突呢？

这是因为技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的；业务也是负责某一部分的业务，也不是和业务的主要目标直接对应的，都是树的分支节点。只有直接解决业务问题的那个技术（或业务）–树的根节点–会和业务直接相关。所以一旦产生冲突，一般必须两个根节点（一般都是领导）碰面才能解决问题，就是这个原因–他们都知道业务主要目标。

这也是为什么下层无法理解上层，而上层都喜欢下军令状，要求下层执行。人只有尽量去理解上层的问题才能做下层的分拆。

在软件行业，这个根节点技术就是软件。这也是为什么架构师要认识什么叫软件，软件解决谁的问题，什么问题，软件本身又是怎么分拆的，才能够更好的组合不同的技术，完成业务的目标。而软件里面和业务直接相关的，只有 Business Domain 这一部分。

用人来打比方，Business Domain 相当于人的大脑，而 Service，Repository，Glue Code 等部分所采用的技术，全部都是计算机自己领域的技术，都是为了能够让程序跑起来，相当于人的四肢。

我们大部分开发人员的工作主要专注于四肢部分。我们真正应该投入的是大脑部分。因为大脑能够决定四肢长什么样，而不是反过来。很多架构师、技术人员主要专注于计算机相关的技术，忽略了业务本身，甚至看不起业务，这也是为什么技术总是和业务冲突的原因。

架构师应该承担起解决业务问题的这个角色，专注于 Business Domain 和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。

只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。