架构设计三原则

笔记

• 业务千变万化，技术层出不穷，设计理念也是百花齐放，看起来似乎很难有一套通用的规范来适用所有的架构设计场景。

• 几个共性的原则隐含其中，这就是：合适原则、简单原则、演化原则。

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

• 脚踏实地”主要体现在下面几个方面。

  1. 将军难打无兵之仗。没那么多人，却想干那么多活，是失败的第一个主要原因。
  2. 罗马不是一天建成的。没有那么多积累，却想一步登天，是失败的第二个主要原因。
  3. 冰山下面才是关键。更多的时候，业界领先的方案其实都是“逼”出来的！简单来说，“业务”发展到一定阶段，量变导致了质变，出现了新的问题，已有的方式已经不能应对这些问题，需要用一种新的方案来解决，通过创新和尝试，才有了业界领先的方案。没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

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

简单原则宣言：“简单优于复杂”。

• 无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则一样适应于架构设计。

• 软件领域的复杂性体现在两个方面：1. 结构的复杂性。2. 逻辑的复杂性。

• 结构复杂的系统几乎毫无例外具备两个特点：组成复杂系统的组件数量更多；同时这些组件之间的关系也更加复杂。

• 组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。

• 某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件。

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

• 逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能。

• 逻辑复杂几乎会导致软件工程的每个环节都有问题。

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

• 对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。软件架构需要根据业务的发展而不断变化。
• 如果没有把握“软件架构需要根据业务发展不断变化”这个本质，在做架构设计的时候就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。
• 软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大。
• 软件架构设计同样是类似的过程：
  1. 首先，设计出来的架构要满足当时的业务需要。
  2. 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
  3. 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
• 架构师在进行架构设计时需要牢记这个原则，时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

理解与思考

• 印象比较深的一点是：软件的主题是变化。在工作中也深有体会。虽然部门设置了一堆的流程来试图减少需求的变化，很显然没起作用。我觉得开发在埋怨需求变化的同时，也要做好设计，拥抱变化。埋怨和消极应付不是长远之计。
• 很久之前我也表达过类似的观点：软件的发展和自然界的进化更类似。
• 以后碰到需求，先做起来，不要过分的追求完美，不要因没有理想的方案而踟蹰不前。
• 软件架构能力是在实践中锻炼起来的。以后学习，一定要注意应用，不能为学习而学习。

课后题

我讲的这三条架构设计原则是否每次都要全部遵循？是否有优先级？谈谈你的理解，并说说为什么。
这三条原则，我理解其实是讲的一件事情，即：做架构设计的时候，以满足当前业务需要为目标，保留演化和发展的能力，不好高骛远，贪多求全。所以做设计的时候，应该都遵守。