持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第5天，点击查看活动详情
架构设计随想
三. 表面复杂度与必要复杂度
既然复杂性无可避免，值得我们深入的讨论分析下。首先我们分析一下表面复杂性和必要复杂性。
表面复杂度 = 系统“难懂的”程度
必要复杂度 = 实现系统功能所需具备的最小复杂度。
比如“三岁的小孩子都能很快自学掌握IPAD”。用上面的定义说，IPAD具有极高的必要复杂度，但是又㮂有极低的表面复杂度。 对比下面的互联网上的段子，相同的必要复杂度下，德国式的走线，明显更好懂。
对架构师来说，在保持必要复杂度相同的情况下，可以通过减少表面复杂度，但是表面复杂度的减少，往往也会提升系统的实际复杂度为代价。所以架构师在应对系统复杂性时，核心策略是：以尽可能小的代价（增加复杂度）来做到尽可能减少系统的表现复杂度。
（是不是觉得有点绕？明白为啥程序员都守不住发际线了吧）
四. 软件系统复杂性的应对之道
大型的软件系统天生具有复杂性，好消息是我们已经从无数的实践中总结了有力的武器来应对复杂性。 首先感谢Grady Booch帮我们总结了复杂系统的5个典型特征，抓住这些特征，我们就可以更好的应对：
1. 层次性
复杂性常常以层次结构的形式存在。复杂的系统由一些相关的子系统缓存，这些子系统又有自己的子系统，如此下去，直到达到某种最低层次的基本组件。
2. 最小组件的相对性
选择哪些作为系统的基础组件在很大程度上取决于系统观察者的判断。对一个观察者来说很基础的东西，对另一观察者可能具有很高的抽象层次。
3. 通用的模式
复杂系统通常都是以一种最经济的方式来实现的。通过由少数的几类的基本组件，按照一些共同的模式组合起来。
4. 关注点分离
复杂系统会根据功能形成各种不同的侧重点，根据侧重点可以划分成不同的子系统，子系统内部的关联的紧密度会比子系统之间更强。
5. 相对稳定的中间形式
复杂系统毫无例外都是从能工作的简单系统演变而来，在动态的演进过程中，会存在相对稳定的中间形式。 基于上述特征，我们可以使用如下的工具来应对复杂性：
1. 分层
分层是隔离业务复杂度与技术复杂度的利器。通过分层来分解不同的关注点，通过分层可以将系统分解为不同的抽象层级。分层的核心在于隔离。
2. 分解
通过分解实现模块化的设计。就是通常所说的高内聚低耦合。一个系统内各个模块在运作时具有一定的独立性，尽可能不受其他模块的影响。模块化的优点是让系统内的不同模块可以根据需要实现深化和适应，而且在特别的情况下还可以实现替换和修改。例如复杂的生命体都具有典型的模块化的特向。感谢模块化可以让心脏移植成为可能（同时祝愿大家永远不需要这个可能）。
3. 抽象
抽象的过程是让我们关注重点的要素，忽略无关紧要的细节的思考过程。通过抽象让我们能够透过现象看到本质，总结归纳出种表象背后相对稳定的规律和原则。抽象帮助我们从大处着眼，具备处理大型系统所必须的俯瞰力。抽象能力的强弱，直接决定我们所能解决问题的复杂度和规模大小。
4. 设计模式
设计模式代表着我们从无数实践中总结出来的斗争经验。大体上讲，一个企业应用软件的功能或数据模型有1/3是所有行业通用的，1/3是具体行业通知的。1/3是企业特殊的。设计模式就代表着2/3部分的设计方法的总结沉淀。“已有的事，后必再有；已行的事，后必再行；日光之下，并无新事”。
5. 迭代
迭代放在最后是想再重点强调一个，**迭代是理解复杂性的关键！迭代是理解复杂性的关键！迭代是理解复杂性的关键！**任何系统都是演进出来的，我们要抓住系统中相对稳定的中间形式，不断的迭代演进。
