各种系统设计文档中，都会有专门的设计原则这个篇章，我记得我在几年前写系统设计文档时，都会觉得这个部分没什么可写的，通常会随便写上几条类似松耦合的原则，并且在之后的概要、详细设计中也不会有什么和设计原则这个部分太相关的部分，这种情况下就会越来越觉得设计原则这个小章节可写可不写，随着近几年从做单一系统到更广的多团队协作的大系统设计后，对设计原则这个章节需要传达的信息有了更多的理解，这篇文章就来谈谈自己的一些感受。

设计原则并不是什么空话，我认为设计原则表述的是架构师对整个系统的核心设计思想，并且要求把这个设计思想贯穿到所有子系统的概要/详细设计中，所以在这些子系统的概要/详细设计中要充分体现出对设计原则的考虑。

对于系统而言，什么才是设计思想呢，每个架构师在做系统的设计之前一般是会有思考的，思考的内容基本就会是要实现需求核心的几个点是什么，这些核心的点就是设计思想，举两个我自己做的设计的例子来说下，会更容易理解一些。

1. 当年在做T4（基于LXC的“虚拟化”产品）时，T4相对以前的Xen，是一个全新的替代产品，在思考T4的设计时，除了一些技术选型外，很重要的一点我判断是对用户透明，对用户而言要做到用的是T4，还是Xen，都感受不到区别，这一点必须贯穿到T4所有部分的设计中，因此这一点就是我当时列入设计原则的。

2. 前几年在做异地多活的设计时，异地多活中最重要的特色是多个异地的机房的数据库都是可写的，在这种情况下在设计的时候要考虑的重点我认为是数据正确性的问题，怎么保证用户数据不会写错乱是关键，所以在设计原则上我写入了数据正确性这条，这样确保了后续在整个跨多个技术领域的子系统的设计中都能仔细考虑数据正确性如何去做到。

3. 还有在做某些系统的设计时，平滑迁移我认为是项目能成功的关键因素，所以在设计原则上我也会写上平滑迁移，确保各个子系统在设计时会把如何从现有迁移到新的结构上放入关键。

从上面的几个例子可以看到，设计原则不仅仅需要表达设计中的一些非常技术层面的共同点（例如关键路径/非关键路径的划分、非关键路径的异步化等），更重要的是表达风险控制要素和优先级，确保在多人合作时整个项目的技术、时间风险的可控，对于一个架构师而言，如何控制好项目在设计、实现时的技术/时间风险，是我一直认为的最为关键的能力，也是我在观察很多架构师时最为看重的。

对于一个大型的项目而言，由于是多团队合作，设计思想的有效传达是非常重要的，设计思想传达的是架构师对整个系统设计的核心思考（不仅仅是结果，更是思考过程），这个思考的表达会非常有助于确保在多个架构师合作的情况下整个系统设计的一致性，以及项目核心目标的完成（之前另外一篇文章的多个团队技术方案冲突的决策原则对系统设计也是非常关键的，没看过的请点击阅读原文查看，相同的是都是把架构师做决定的背后的原因讲清楚，以便多人协作，仅传达结果没有过程的那种是很难真正达成一致和留下深刻印象的），不过即使是小的单一系统的设计，就算架构师是同一个人，设计原则这块也需要陈述清楚，以确保在做各子模块设计时能遵守，同时也是让实现各部分代码的同学能更容易理解设计。

=============================

欢迎关注微信公众号：hellojavacases

公众号上发布的消息都存放在http://hellojava.info上。