目录

• 合适原则
• 简单原则
• • 结构的复杂性
  • 逻辑的复杂性
• 演化原则

合适原则

合适原则宣言：合适优于业界领先

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。

踩坑点：

1. 将军难打无兵之仗，没那么多人，却想干那么多活；
2. 罗马不是一天建成的，没有那么多积累，却想一步登天；
3. 冰山下面才是关键，没有那么卓越的业务场景，却幻想灵光一闪成为天才；

简单原则

简单原则宣言：简单优于复杂

复杂在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是问题(下文说明)

软件领域的复杂性体现在两个方面：

结构的复杂性

结构复杂的系统几乎毫无例外具备两个特点：

• 组成复杂系统的组件数量更多；
• 同时这些组件之间的关系也更加复杂。

结构上的复杂性存在的第一个问题是：组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。

结构上的复杂性存在的第二个问题是：某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件。

结构上的复杂性存在的第三个问题是：定位一个复杂系统中的问题总是比简单系统更加困难。首先是组件多，每个组件都有嫌疑，因此要逐一排查；其次组件间的关系复杂，有可能表现故障的组件并不是真正问题的根源。

逻辑的复杂性

如上文所述，为了降低结构复杂，减少系统中的组件数量，最简单的结构就是整个系统只有一个组件，即系统本身，所有的功能和逻辑都在这一个组件中实现。

不幸的是，这样做是行不通的，所有功能和逻辑都在一个组件中实现会造成这个组件逻辑特别的复杂。

逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能；
另一个典型特征就是采用了复杂的算法。复杂算法导致的问题主要是难以理解，进而导致难以实现、难以修改，并且出了问题难以快速解决。

逻辑复杂几乎会导致软件工程的每个环节都有问题，假设现在淘宝将这些功能全部在单一的组件中实现，可以想象一下这个恐怖的场景：

• 系统会很庞大，可能是上百万、上千万的代码规模，“clone”一次代码要 30 分钟；
• 几十、上百人维护这一套代码，某个“菜鸟”不小心改了一行代码，导致整站崩溃；
• …

为什么复杂的电路就意味更强大的功能，而复杂的架构却有很多问题呢？

根本原因在于电路一旦设计好后进入生产，就不会再变，复杂性只是在设计时带来影响；而一个软件系统在投入使用后，后续还有源源不断的需求要实现，因此要不断地修改系统，复杂性在整个系统生命周期中都有很大影响。

演化原则

演化原则宣言：演化优于一步到位

软件架构从字面意思理解和建筑结构非常类似，例如，软件架构描述的是一个软件系统的结构，包括各个模块，以及这些模块的关系；建筑架构描述的是一幢建筑的结构，包括各个部件，以及这些部件如何有机地组成成一幢完美的建筑。

然而，对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。软件架构需要根据业务的发展而不断变化。

考虑到软件架构需要根据业务发展不断变化这个本质特点，软件架构设计其实更加类似于自然进化，通过迭代让系统逐步变得强大：

• 首先，设计出来的架构要满足当时的业务需要。
• 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
• 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等却可以在新架构中延续。

如此在进行架构设计时应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

--------来源《极客课程》∙ 学习摘要