架构是一个约定，一个规则，一个大家都懂得遵守的共识。
那这是什么样的约定、什么样的规则、什么样的共识呢？
我以包为例，我经常出差，双肩背包里装了不少东西。笔记本电脑、电源、2个上网卡、鼠标、USB线、一盒大的名片、一盒小的名片、口香糖、Mini-DisplayPort转VGA接口、U盘、几根笔、小螺丝刀、洗漱用品、干净衣服、袜子、香水、老婆给我带的抹脸膏（她嫌我最近累，脸有点黄）、钱包、Token卡、耳机、纸巾、USB线、U盘等。这个包有很多格子，最外面的格子我放常用的，比如笔、纸、一盒小的名片等；中间的格子一般放的是衣服、袜子、洗漱用品、香水等；靠背的那个大格子放了笔记本电脑，和笔记本电脑相近的小格子放的是两个上网卡、Mini-DisplayPort转VGA接口、大盒名片、记事本，和笔记本电脑相近的大格子放的是电源、鼠标、口香糖等。
我闭着眼睛都可以将我的东西从包里掏出来，闭着眼睛都可以将东西塞到包里！但是，非常不幸的是，一旦我老婆整理过我的包，那我就很惨了，老是因为找不到东西而变得抓狂！更不幸的，要是我那个不到两岁的“小可爱”翻过，就更不得了了。
这个包就是我放所有物品的“架构”，每一个东西放置的位置就是我的“约定、规则、共识”。倘若我老婆也知道我的“架构”、我的“约定、规则、共识”，那么不管她怎么动我的包，我都照样能够轻易的拿东西或者放东西。进一步，如果我的同事也知道我的“架构”，知道我的“约定、规则、共识”，那么他们什么时候动我的包，我也毫无所知！
恍然大悟！我前一个公司Sybase，所有的产品都是基于一个统一的插件开发平台，每一个产品都是一个插件，每一个插件都按照名字约定好了BO(Controller)、GO(View)、SO(Model/DataAccessor)，定义好PropertyPage、PropertyDialog、Wizard。我记得当我确定工作角色后，我就拿到一个开发文档，里面描述了这些目录、名字的规则，有UI文字陈述规则、文字的大小规则等，一周内我就能够修Bug，一个月之后我就能做New Feature，然而，我此时对我们的平台、框架依然一无所知。过了1年后，产品依然遵守约定不断进行改进，在维护过程中，我们竟然丝毫没有感觉到累。基于这样的框架做产品，我发现不管是什么人，开发的样式都完全一致。我以前竟然丝毫没有觉得惊讶！
在公司混了两年之后，有点成为老鸟了，还很得瑟的整了一个《Flex UI Composition SDK》，就是基于Flex的界面组合组件，搞的老漂亮了，代码写的好看，文档搞的正式，而且这个小SDK功能强大且很灵活。老大很给面子，让我给美国的架构组Show一下。我很激情的在半夜里用电话会议和那帮很牛的架构师、专家级工程师展示我的SDK。完事后，印象很深刻，一个很资深的老外架构师提了一句，他觉得这个SDK有点复杂。
以前我不太理解为什么他会说复杂。原因很简单，以他的技术，使用这个SDK我觉得没有太大的问题，只要稍稍学习就好了。后来，我终于慢慢想通了。这个SDK不好的地方在于太灵活了，灵活到无法构建一个统一标准的、容易让人遵守的“约定、规则、共识”。在没有“共识”的支撑下，这样的系统经过若干人维护后，那绝对玩完了，成“万人坑”了，谁改代码就坑谁，以后什么事情都有可能发生的。
于是，我有一点点想明白了，架构就是这么的一个共识。当共识普遍传递的时候，架构就消失了，开发好的软件就成为了习惯。
这就是为什么有高人提出“消灭架构”！
哦，天啊，这帮人太变态了，他们这么早就想通了！
第一步：使用插件架构
第二步：定制统一的界面框架
这个界面框架如下所示。
该框架约定了统一的界面样式，比如按钮、磁贴、标签页、导航条、进度条、Form等等。
第三步：定制插件的统一架构每一个插件都创建5个目录：Controllers、DataAccessors、Models、ViewModels、Views，如下所示。每一个目录存放的代码通过名字都知道是什么了。
第四步：定制开发模板（升华，该步骤不是必须的，是为了更好提高易用性，让傻瓜也可以开发插件，仅供参考）
在主程序模板可以保护统一数据访问、统一安全管理等功能模块。
哈哈，这个方法终于能使新团队开发出具有较为统一风格、较高质量的软件产品了！这时候，你会发现，所有人都不需要关心架构了，我们只有共识。
这样，架构被成功消灭了，架构的目标就是消灭架构！但是，如果架构被消灭了，架构师不也被消灭了吗？这个搞笑的问题留给读者吧。
附：关于架构的官方定义，建议参考《Java应用架构设计》，该书很经典。本文关于“架构就是共识、消灭架构”说法，来自于该书。我不是“架构就是共识、消灭架构”说法的发明者。
