架构设计三原则

脚踏实地”主要体现在下面几个方面。
1. 将军难打无兵之仗。没那么多人，却想干那么多活，是失败的第一个主要原因。
2. 罗马不是一天建成的。没有那么多积累，却想一步登天，是失败的第二个主要原因。
3. 冰山下面才是关键。更多的时候，业界领先的方案其实都是“逼”出来的！简单来说，“业务”发展到一定阶段，量变导致了质变，出现了新的问题，已有的方式已经不能应对这些问题，需要用一种新的方案来解决，通过创新和尝试，才有了业界领先的方案。没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。
真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。

无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则一样适应于架构设计。
软件领域的复杂性体现在两个方面：1. 结构的复杂性。2. 逻辑的复杂性。
结构复杂的系统几乎毫无例外具备两个特点：组成复杂系统的组件数量更多；同时这些组件之间的关系也更加复杂。
组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。
某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件。
定位一个复杂系统中的问题总是比简单系统更加困难。首先是组件多，每个组件都有嫌疑，因此要逐一排查；其次组件间的关系复杂，有可能表现故障的组件并不是真正问题的根源。
逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能。
逻辑复杂几乎会导致软件工程的每个环节都有问题。

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

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

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