具体情境决定一切

作者：爱德华·加森（EdwardGarson）

分享设计架构的理念让我们觉得很滑稽，因为我认为压根儿就不存在设计理念。如果我是对的，就无从下笔了，好在我是个矛盾的人，愿意冒险做些太阳打西边出来的事儿。

毕竟，没有理念本身就是一种理念。

对我来说最重要的设计经验是：具体情境（context）决定一切，根据它设计尽量简单的解决方案。换句话说，架构决策只有在情境需要时，才能牺牲尽量简单的原则。

我说的情境不仅指业务目标这种高层的、直接的因素，还包括其他外界因素，比如各种新兴的技术和创新的思想。称职的架构师应该多关注发展迅速的新技术。

高品质的架构师是由什么构成的？架构是在具体情境下据作出的一系列决策，用心实现一组通常相互制约（竞争）的需求。由于需求常常相互制约，所以设计架构的关键不是贡献新内容，而是忽略那些不必要的需求。设计架构的过程其实是作出明智决策的过程（产品则体现了架构师的设计意图）。

具体情境影响架构的先例很多，其中不乏生动的故事，比如大家津津乐道的挑选M1艾布拉姆斯主战坦克（M1 Abrams tank）车载数据库的例子（译注1）。（当然，挑选数据库通常不是设计架构的重点，举这个例子只是为了说明应用情境的重要性。）

M1坦克的设计团队评估了许多数据库。坦克必须在起伏不平的地形上高速行驶追踪目标，导航系统和觅标系统的数据吞吐量很大。设计团队发现大部分数据库可以满足最严格的要求，可是坦克主炮射击产生的巨大电磁脉冲会彻底破坏车载软件系统，包括数据库。在现代战场上，没有软件的坦克只能像瞎子一样乱窜。在这种情况了必须迅速恢复数据库，当时InterBase数据库的表现最出色（译注2），所以被选为M1坦克的车载数据库。

我觉得论坛讨论组上那些激烈争论技术优劣的人，不过是茶余饭后寻消遣。他们争论的并非悬殊的技术差异，不过是些细微的不同之处，更何况脱离了具体的应用情境，孤立地比较技术的优劣是毫无意义的事。

别让团队成员被各种设计理念束缚住，鼓励大家具体情况具体分析，努力找出最简单的解决方案。

译注1：虽然制造坦克的目的可疑，但不可否认设计难度非常大。

译注2：InterBase数据库的磁盘写操作可以保证数据库与磁盘始终处于一致的状态，这是它能迅速完成灾难恢复的原因。