2.5 架构是什么

最后，笔者抛出3个观点来谈谈架构是什么。

回顾一下前辈们对“架构是什么”的看法——有组成派和决策派两派观点，而我的观点是：架构兼具组成和决策的特点，架构之于架构是自包含关系。

2.5.1 架构兼具组成和决策的特点

Mary Shaw在《软件体系结构：一门初露端倪学科的展望》一书中论及软件系统的架构时，将系统描述为组件及组件之间的交互。而“Rational统一过程”则重点表达了以下观点。

软件架构包含了关于以下问题的重要决策：

●如何对软件系统进行组织。

●如何选择组成系统的结构元素和它们之间的接口，以及如何设计当这些元素相互协作时所体现的行为。

●如何组合这些元素，使它们逐渐合成更大的子系统。

●如何让用户知道这个系统组织的架构风格：这些元素及它们的接口、协作和组合。

软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制与权衡，以及美学。

2.5.2 架构是演进来的

架构是演进来的，是动态的。业界关于架构是预先设计出来的还是演进出来的颇有些争论（《恰如其分的软件架构》一书就提及了计划式设计、演进式设计等观点），笔者的观点是比较明确的，不倒向任何一方，而是认为：

●软件架构需要事先设计，而演进式架构号称是采用TDD、重构、持续集成等手段保障其演进的。但敏捷实践里面的 TDD 是从微观视角来看的，重构也可以以微观视角进行。宏观视角需要对整体架构进行设计，让参与者具有共同的愿景，并做出共同的决策。比如，技术框架如何选型、怎样评估用户并发、用户是谁，以及如何提供服务等。

●不做BDUF，暂缓做不确定的事，不做大投入的方案。任何一个选择都需要考虑投资回报率（ROI）。

●架构处于一个动态的过程中，是不断演进的。除了微观的重构及敏捷实践会演进，领域模型和架构方案亦可持续演进。

●偿还技术债务、重构和不断抽象、分解问题域是演进的一些手段，保持架构演进要特别持续关注质量并保障其没有下降。

图2.17是一个大公司架构生命周期的活动图。从架构规划到架构实施，其中有不断的沟通。而架构实施的反馈又将纳入下一代的架构规划中。下一代的架构规划，一方面要纳入现阶段的问题，另一方面要基于行业领域知识、同行参考和商业洞察进行。

2011年，我们做过一个不太成功的示范，在产品层之下设计了一个基础层，做核心领域的沉淀，后来孵化出了10多个小产品，结果核心的两张表被过度抽象，但这对于不确定性很强的业务是不合适的。完全烟囱模型+插件（或工具黏合剂）的方式可能更合适。

2.5.3 无纯粹的非功能特性

这一节其实想表达的是功能特性与非功能特性的区分不够好。什么叫非功能特性？有人也称之为质量特性。笔者觉得一切都是质量，所以在商业需求呈现过程中一定要区分下面两条需求的意义其实不大。

●登录3次，锁定账号20分钟。

●系统需要支持2000个用户同时并发。

另外一个区分功能特性与非功能特性的危害是容易把非功能特性当作增强性要素。增强性要素就是重要但紧急程度不高，可以让用户先用起来的要素。

笔者的观点很明确，应该把所有需求放到一起排序，而基于安全性、高可用性这些面向切面的分类，只是为了更好地管理架构的各个组成部分而已。同时，在团队分工上也可以做到术业有专攻。以图2.18为例，可以看到每个约束要求都对应具体可操作、可验证的功能，比如数据安全性、通信安全性。