极客时间：《从 0 开始学架构》架构设计三原则

引言

合适原则、简单原则、演化原则

合适原则

合适原则宣言：“合适优于业界领先”。
再好的梦想，也需要脚踏实地实现！这里的“脚踏实地”主要体现在下面几个方面。

• 1. 将军难打无兵之仗

没那么多人，却想干那么多活，是失败的第一个主要原因。

• 2. 罗马不是一天建成的

没有那么多积累，却想一步登天，是失败的第二个主要原因。

• 3. 冰山下面才是关键

业界领先的方案其实都是“逼”出来的！简单来说，“业务”发展到一定阶段，量变导致了质变，出现了新的问题，已有的方式已经不能应对这些问题，需要用一种新的方案来解决，通过创新和尝试，才有了业界领先的方案。
没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。
所以，真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。

简单原则

简单原则宣言：“简单优于复杂”。
“复杂”在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是“问题”。
软件领域的复杂性体现在两个方面：

• 1. 结构的复杂性
     结构复杂的系统具备两个特点：

1)组成复杂系统的组件数量更多；

组件越多，就越有可能其中某个组件出现故障

2)同时这些组件之间的关系也更加复杂

某个组件改动，会影响关联的所有组件
定位一个复杂系统中的问题总是比简单系统更加困难

• 2. 逻辑的复杂性

逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能。以电商业务为例，常见的功能有：商品管理、商品搜索、商品展示、订单管理、用户管理、支付、发货、客服……把这些功能全部在一个组件中实现，就是典型的逻辑复杂性。
为什么复杂的电路就意味更强大的功能，而复杂的架构却有很多问题呢？根本原因在于电路一旦设计好后进入生产，就不会再变，复杂性只是在设计时带来影响；而一个软件系统在投入使用后，后续还有源源不断的需求要实现，因此要不断地修改系统，复杂性在整个系统生命周期中都有很大影响。

所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则一样适应于架构设计。

演化原则

演化原则宣言：“演化优于一步到位”。
对于建筑来说，永恒是主题；而对于软件来说，变化才是主题
如果没有把握“软件架构需要根据业务发展不断变化”这个本质，在做架构设计的时候就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。
考虑到软件架构需要根据业务发展不断变化这个本质特点，软件架构设计有着这样的过程：

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

架构师在进行架构设计时需要牢记这个原则，时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

所思

在我们部门的业务中，主要负责应用层的任务，经过未曾谋面的大佬重构之后全部已逐渐化的多形式存在，在日常的开发任务中，极大的缩短了开发周期。
从业务需求上来看，各个功能模块为独立的个体，适合组件化的方式进行开发，且在定位问题上能够快速定位