架构设计是一个很有意思的话题，有时候容易过度重视，有时候又过于轻视这件事情。这一方面是因为所谓架构，很难有一些定量的指标去衡量它的优劣，而且面对具体的情况，其方案和侧重点都会有许多的不同，即便同一情况下，也有不同的思路可以达到最终目标，没有一个绝对标准的答案。

Beautiful Architecture一书里讲到了一些架构设计的基本原则和特性，通过这些基本原则，在某种程度上是可以衡量一个架构优劣的标准。这里只记录我对其中几点的一些个人体会，这几点包括了Versatility, Independently changeable, Automatic propagation, Growth accommodation, Entropy resistance。

Versatility

最灾难的架构设计莫过于发现此架构不能满足所有的需求，或者某些需求是要以大幅度修改框架基本设计为代价才能实现的。如果这是一个已经投入使用的产品的架构，那么带来的麻烦可想而知，而在现实情况里，这往往就变成了以己之矛攻己之盾的故事，所有人都觉得受了委屈，于是不了了之，最终为未来埋下无穷的隐患。

Independently Changeable

这基本是分层设计的最终目的，或者说，SOA在一定程度上也是为了这样的特性。不过在现实当中，其实很难在这点上做到全功，有些时候是这因为我们的错误，把逻辑上有着千丝万缕联系的东西故意分割开来。抱着strong cohesion and low coupling的原则并没有错，但要真正把握那条隐约可见的分隔线却不容易，这需要丰富的实际经验才能做到。另一方面，即便能够正确的划分，设计各模块之间的通信契约也是个十分精巧的活儿。总之，这是看起来不难，能做的好的不多的一点。

Automatic propagation

能够体现这一点的实际情况是元编程的运用，在构建一个系统的过程中，总有各种重复的行为出现，如何最大限度的减少这些重复工作量，也是一个好架构设计的关注点之一。这对保持一致性和正确性来说也是有很大的帮助。

Growth accommodation

这是近些年来最受关注的一方面吧，对于许多Web application来说，可扩展基本上是最优先考虑的要素。这方面的内容已经很多，就不多说什么了。但如果一个大型Web应用不考虑这点，基本上是无法持续发展的。

Entropy resistance

这一点很有趣，但有实际经验的人都知道，系统永远是在不断改变和增加新需求的情况下变得混乱，这就像建好的房屋会在各种不同的装饰和修缮之下可能变得面目全非一样。组织越大，就会越来越混乱。所以，架构师需要在设计时便确立各种一致的准则和规范，同时让开发人员能够理解和遵守，这是架构师很重要的职责之一。否则，当系统变得越来越混乱时，没有人会愿意去重新修改它，因为光想到那些细枝末节都让人头疼。从另一个角度来看，当团队中有新的人员加入时，他是否能够很快的熟悉原来架构的思路和准则，并且在开发中能够很清楚地就明白自己所编写的代码应该放置于系统中的什么位置，也体现了这个架构抵御熵的优劣。同时，熵并不完全是技术人员带来的，这个道理在最后讨论Architecture的真正定位时会提到。

这些基本的准则并不是每一条都一定要满足，根据实际项目的不同，会有不同的侧重点。而经常出现的误区是，所有人从一开始都不断地在关心performance，或者深陷于security当中。

关于performance，其实对大多数人来说都是一个迷，甚至大部分人都并不真正了解他们应用的性能数据，而他们在一开始最担心的情况，也许永远都不会出现。好的架构设计总是让性能调优能够通过很简单地系统化手段解决，因为其能准确找出出现性能瓶颈的区域，并将调优的手段融入架构之中，这也是Independently Changeable的意义所在。而且，性能的优化应该始终置于可扩展的基础之上再考虑。同时能够对未来的技术进步趋势做出正确的预判也是决定调优的重要因素。

架构所关心的security，与通常所理解的security可能并不完全是一个范畴。应用的Security，架构只能在框架的实现过程中解决一部分基本的，更多的则要靠在应用本身之外解决。架构或许需要考虑部署上的那些细节，但并不是最重要和最优先的事项。

总体而言，对架构设计的最大误区是认为这是一个纯技术范畴的工作。确实这需要扎实的技术功底，但不仅仅是如此，之所以用Architecture这个词，就是为了说明其最重要的职责是首先能明白最终要实现的是一个怎样的东西，是一所教堂，还是一个游乐场。Architecture是连接最终需求和最终成品的关键点，在建设完成之前，教堂或游乐场已经真实地存在于Architecture的脑海之中，而他则完成基础的规划，告诉人们该如何建造它，并确保最终的成品不偏离目标并且是一个完整，可用的实体。

但事实上，经常出现的错误要么是狭隘地理解了这个角色的定义，要么是给这个角色规划了不恰当的职责范围。