什么是软件架构？

和“软件的体系结构”有什么差异？

架构设计是做什么？怎么做的？

软件架构师是神马角色？

这些问题都曾经是困惑国内软件设计人员的问题，对于普通的软件用户而言，则更加感觉经常被这个词忽悠。

本文试图对软件架构的知识进行一点科普。

回答什么是软件架构之前，先理解什么是“架构”。

对“架构”一词，我不准备去翻译解释其英文原始词汇architecture的含义，也不准备让大家从理解建筑设计师的职业开始来说明。而是从“系统科学”的1+1>2的著名观点开始。

怎么理解系统科学里所讲的1+1>2?

这并不是个简单的算术误答，而是说的这样的一种事实：一个系统总是会表现出一些特征，而这些特征是其任何一个局部部分都不单独具备的。 只有将这些系统的各个部分，“有机”地组织构建起来，才会让这个系统的整体，“涌现”出这些在局部上所不具有的特征来。

这么说，还是比较抽象。

所以，还是用我所理解的时装设计来比喻吧。

我理解的时装，代表的是一种在穿着打扮方面的流行时尚。简单地说，就是设计一种穿著打扮的方法，让适合这类穿著打扮的人，穿著打扮起来给人耳目一新的感觉。

当然，我们知道，这种感觉，绝对是实在的感觉，你可以明显地感觉到的那种“与众不同”，和“与往不同”。而设计师造就这种感觉的方法，只不过是用模特的体貌特征和布料服饰等“素材”。设计师，只是用自己提供的某种“搭配”的方法和技巧，就能成功地创造出一种全新的感觉来。而这种“给人全新的感觉”的能力，是设计师所用的任何一种“素材”所不具备的。

这，就是典型的“1+1>2”，这或许也是“创新”一词的含义之一：不是你找到了一种方法，可以让一些事物按某种方式搭配起来，产生出某种局部所不具备的特征来了，就叫创新，而是这种特征本身，是以往在任何地方任何人处都没有出现过的这样的特征或这样的搭配方法，就可以叫创新了。

如果到这里，我已经把1+1>2的道理讲清晰了的话，我就基本上讲清了什么是“架构”了。

如果我们实在是无法摆脱“系统是由部分组成的一个整体”这样的传统思维惯性，又总是在纠结着：这样的表达让我们丢失了系统整体所超出各部分之和的信息，这个问题的话，我们其实可以稍微变化一下想法：为什么我们不增加一个“额外的部分”的概念呢？在我们理解的系统是各部分组成之和中，增加被我们没有表达出来的“部分”，不就不用纠结这个问题了吗？

也就是说，其实，不是１＋１＞２，而是，１＋１＋１＝３＞２．

这么理解，带来的新问题是：这被我们新发现的这个部分，到底是什么？

为什么我们明显可感知到它的存在，而我们又总是觉得它有点虚无飘渺？

我们遇到了新的困惑。

正好，在另外一帮家伙哪里，他们遇到了一个似乎正好相反的问题。

他们也明显感觉到被他们所构造的事物，呈现了他们用来构造这个事物的局部所不具备的特征来了，事实上，这正是他们的使命。他们的职业就是要做到这个才能领到工资——他们要是没能构造出这些特征来，就不该拿到薪水。

而他们的问题是：他们并不太留意这么来理解他们所做的工作及其价值，而又在困惑：对于被他们称为“架构设计”的工作，总找不到某种理论上的说法，让他们和他们的用户踏实感受到这部分工作从内容到价值上的准确定位。

这帮家伙，就是软件架构师。

正好有个家伙，他看到了系统科学上的那个困惑和软件架构师的困惑的互补性。

系统科学上的困惑其实只是：没有找到一个合适的词汇，来指称那额外多出来的部分。而系统架构师的困惑只是：找到了一个合适的词汇“架构”，却不知道这个词汇指的就是那“多出来的部分”。实际，大家对“确实存在多出来的部分”的事实并不陌生。

为什么不直接了当地这么解决掉双方的困惑呢？

因为，到现在为止，貌似还只有这一个家伙发现了这个事情。这个家伙，就是我。