任何在IT公司工作的人，对于架构这个词应该都不陌生。但你去问架构这个词是什么意思，似乎又有点只可意会不可言传的意思。那么

这篇文章，会尝试讨论一下上面这些问题。

如何定义架构设计？

我们先来看一个古老的的思想实验：

哲学家们为了这个问题争论不休，而它也被称为忒休斯悖论。忒休斯悖论实际上问的是，一个物体是不是等于组成它的各个部分的总和？如果答案是肯定的，那么当船上所有木板都被更新了，那么这条船当然是一艘完全不同的船了。但是，直觉告诉我们，这条船还是原来的那条船啊。如果不是这样，一所学校，学生几年就全换一遍，老师几十年全换一遍，难道这所学校就是一所新的学校了？一条河，河里的水奔流不息，难道这条河就不是原来那条河了？也就是说，我们凭直觉知道，一个物体并不等于组成他的各个部分的简单加总。那么，它到底等于什么呢？

要回答这个问题，就需要引入系统论的观点了。科学研究的主要方法，是把复杂事物拆解成一个个简单模块来分析，这种思维模式叫做还原论。然而，人们发现，还原论可以很好地解决单个事物的问题，却很难解决系统性、结构性的问题。想要解决这些复杂问题，必须重新回到整体论，而系统论正是研究这一领域的学科。

在《系统之美》这本书中，系统不是一堆事物的简单集合，而是由一组相互连接的要素构成的、能够实现某个目标的整体。任何一个系统都由要素、连接和功能（目标）构成。譬如对于忒休斯之船，其要素是一堆木板，连接是这些木板的位置和铆合关系即结构，而功能就是航行。系统论讲的是广义上的系统，房间的温度、公司的经营、国家的经济，都可以用系统论的模型去进行描述。

软件系统，也是一种系统，因此也可以用系统论的方法进行描述。架构就是构成软件系统的要素、连接和目标。架构设计就是找到软件系统中的要素，并将要素之间的连接描绘清楚，从而实现软件系统目标的过程。

为什么架构这么重要？

架构清晰，才能理解问题

《系统之美》的作者说，当我们看一个系统时，往往只会注意到系统的要素，而忽略掉系统的连接和目标。但对于一个系统而言，要素往往不是最重要、随时可以替换的。如果改变了系统的连接，那么系统就会发生巨大的变化。譬如在大学里，如果不是教授给学生打分，而是学生给教授打分，那么大学就不再是大学而是商业培训机构。而比连接更重要的是目标，譬如大学的目标如果不是教书育人，而是赚钱盈利，大学也会成为一种系统。

软件系统是一种非常抽象和复杂的系统，软件系统的构造是一个非常复杂的问题。普通人去理解软件系统往往只能看到其中的要素（功能模块），而看不到要素之间的连接（模块之间的关系），但如果不能确定功能模块之间的关系而直接进入到开发状态，由多人或多个组织单元从事的软件系统的开发就会陷入混乱，在耗费大量的人力物力和时间成本后，发现难以达成想要的目标，只留了一堆需要继续投入人力成本维护的代码。

架构合理，才能应对变化

《人月神话》中有一句名言：软件开发过程中，唯一不变的就是变化本身。变化就会带来软件系统的熵增，即软件的生命力从最初的理想状态，逐步趋向于复杂、混乱和无序的状态发展，直到软件不可维护而被迫下线或重构。显而易见，对于从事软件系统开发的商业组织而言，熵增的后果就是无法满足客户需求导致的收入减少和成本居高不下。而业界多年成功和失败的经验已经证明，软件系统熵增的根本导因就是架构设计被忽视。

例如大多数软件项目都采用了快速迭代的开发方法，即从软件的一小部分重要功能模块开始开发，逐步增加新的功能模块。这种方法带来好处的同时也带来了问题，系统开发过程中会不断引入新的要素（功能模块），这些新的要素的引入很可能会打破原本已经存在的要素之间的连接（功能模块之间的关系）。如果在开始开发之前没有进行架构设计，将所有重要的要素都找出来、理清要素之间的连接并证明其可以支持系统达成最终的目标，那么在开发过程中就会需要不断进行重构，或者因为技术无法实现而放弃某些功能。

架构稳定，才能积累能力

得到App《启发俱乐部》第29期《能力如何增长？》中有这样一段话：

玩儿过Linux的程序员应该都听说过神的编辑器"Emacs，这是一款1975年开始开发并至今仍有用户使用文本编辑器，而它居然还能支持多种1990年代后出现的编程语言的开发与调试。相似的例子还有Eclipse，它除了作为最初的JavaIDE，还被改造为多种其它用途。

为什么这些软件能够经过数十年的发展依然经久不衰，支撑了在当年不可能预见的需求；而有很多软件产品每隔三五年就要进行一次完全的翻新、不能在最初的版本上进行向前兼容的演进，不断积累能力？因为在进行软件产品开发前没有进行必要的架构设计，这样就根本找不到那一组永恒的问题。于是面对客户的定制需求时，就只能真的定制，给出无数不能指向能力积累的解决方案。

这种状态不仅导致软件系统的交付周期延长、质量下降，也会导致提供软件产品或服务的商业组织大量收入变为成本而无法成为利润。

软件系统的架构如何描述

关于软件系统的架构如何表达方法，在行业里争论就比较多了，由于所处的环境和工作背景的不同，每个人的理解都不太一样。但目前在行业中，有一些共识是架构的表达需要分层分类，不可能简单的用一张PPT就描绘清楚软件系统架构的所有问题。

行业中比较常见的关于架构分层分类的方法是：业务架构、应用架构、数据架构、技术架构。这些词被放到不同的环境中时，其具体含义也会发生一些变化，但其底层逻辑是一致的。

在上述四类架构设计工作中，应用架构通常是最为薄弱的环节，因为业务架构可以由不特别懂技术的人做，技术架构可以由不特别懂业务的人做，而应用架构需要能深刻理解业务又懂技术的人做，这样的能力往往需要多个工种的工作经验和长时间的积累才能获得。当然，应用架构做的越好，也越容易给商业组织带来竞争力。

结语

如前文所述，如果在软件系统开发前，没有将架构问题解决，那么会给开发工作带来无尽的麻烦。而对于从事TOB软件产品或服务开发的商业组织而言，因其所提供的产品或服务要面对不同客户，也一定会面对不同客户的不同需求所带来的定制化问题，架构设计的重要性就更加不言而喻。

因此在产品或服务的立项阶段和研发过程中的设计阶段，就必须将业务架构、应用架构、数据架构和技术架构中的关键问题描述清晰，并且该产品或服务的功能越多、部署方式越复杂就越需要认真完成这一工作，不可绕过。如果只是把UI/UE设计完成就开展相关的研发工作，一定会在熵增的路上越陷越深。