你有没有听过四维架构？
在程序员界流传着很多传说，这些传说由于历史太过久远，渐渐被人们遗忘，只剩下一些流行的名词，比如架构，银弹，程序员三大爱好，重构，人月，设计模式等等。今天我们就来讲讲架构，而且不是普通的架构，是一个可能你听都没听说过的四维架构。
架构是什么
行业里并没有一个明确标准的关于架构的定义，有些人按照系统的组成结构来定义架构，有些人根据系统设计遵循的决策来定义架构。这里我们采用关于 rest 那个著名的论文里的定义：架构是系统运行时的高层抽象
架构存在的理由
- 交流的需要
人类使用语言来交流的只能是概念和抽象，我们实际上无法使用语言传达一个真实存在的事物，所以你跟一个没有桌子这个概念的人是无法交流桌子的，而你要传达桌子这个概念时，也只能使用柱子，平面等等这些概念。
所以当我们在讨论一个系统时，通常讨论的是概念模型或抽象。如果讨论的是一些类型系统时，比如分布式，大数据处理，我们通常会使用概念模型，比如分布式事务，两阶段提交就是两个概念模型。当我们在讨论一个具体的系统时，我们通常使用的是抽象。网上搜到某某系统的架构图，其实就是系统的高层抽象，所以至少为了交流，我们也需要架构。
- 设计的需要
我们最终的目标是要实现一个存在指定功能集并且实际可运行的系统。为了达到这个目标，我们通常会有两种方式。拿画画来做比喻，你即可以直接开始画，也可以先构图。基本上来说，如果你胸有成竹了，那就可以直接上，如果没有，那还是先做设计比较好（ TDD 倡导的简单设计，也是设计的一种）。
假设我们选择了先进行设计（这个也是大部分非个人项目的实际选择），那么我们进行的就是架构设计。所以要有架构这个概念的存在，才能做架构设计。
- 决策的需要
无论是上层设计时，还是具体开发过程中，我们常常需要面对一些选择，比如通讯方式选择那一种，又比如执行方式应该是同步还是异步，又或者应该返回空还是抛出异常。当我们面对多种选择时，需要一个准则来指导我们做出正确（至少是一致）的选择。而这个准则就来自于架构。
架构设计的原则
《大道至易》里说架构设计通常是带有架构意图的，而架构意图则是架构师分析完一个系统之后产生的。面对不同的系统，产生的架构意图也会不同，当然设计的架构也不同。然而我们依然可以总结出一组较为通用的原则来设计架构，就像程序设计领域的 solid 原则一样。 Stephen Mellor 在《架构之美》里讨论了7个架构原则。
- 概念完整性
- 功能多样性
- 增长适应性
- 修改独立性
- 熵增抵抗性
- 可构架性
- 自动传播
架构设计的方法
Roy Thomas Fielding 在他的博士论文里介绍了两个架构设计的方法。
- 根据已存在的一组架构风格做为基础进行修改调整。以得到满足目标架构约束的一种架构风格（也可以是具体的架构）
- 分析目标架构的各种约束条件，根据约束条件选择模式，通过模式组合形成一种满足所有（或者大部分）约束条件的目标架构。（具体模式和约束条件的对应关系，以及论证可以参见论文）
另外还有 RUP 的 4＋1 的视图方法。或者《软件架构设计》上说的五视图方法。都有讨论架构设计的方法，感兴趣的可以找相应的书籍来看。
四维又是什么
上面说了这么多关于架构的东西，那么四维又是什么呢？四维其实就是比三维多一维（时间纬度）。所谓四维架构就是随着时间会成长的构架。
这个世界上唯一不变的就是变化，架构会随着时间变化不是一句废话嘛。其实不然，变化不等于成长。不同的架构熵增抵抗性是不同的，大部分架构随着时间流逝，以不同的速度腐烂老去，最后死亡。另外一些好的架构，则随着时间不停的变化以适应新的情况。
是不是这些好的架构就是我想说的四维架构呢？虽然也可以说这些好的构架确实是随着时间“成长”的架构。但是通常这种“成长”是随机的，不可测的。其结果就是虽然一年后这个系统还是一个运行良好并且拥有良好架构的系统，但这个架构一定跟一年前很不一样了，甚至不太认得出来了。
一条小狗长大后，不可能变成一只猫，所以四维架构就是一个架构在成型的那一刻就确定了它永远的样子。通俗点说就是四维架构是拥有基因的架构。那么怎么设计一个拥有基因的架构呢？
最后说两句
感觉这篇文章被我写烂了，后面实在编不下去了。但是我又不想去掉四维，把它变成一篇单纯写架构的文章，因为我写它的目的就是为了写四维，可能这个概念在我脑中还没完全成型吧。
