1
风格对于软件系统，犹如文化对于人类社会，对于组成系统的各个要素(无论模块、组件、对象还是函数)，都会施加影响，只要是在运用该风格的边界范围之内。
这种风格影响如文化烙印一般，体现出一种强烈的一致性。当然，一旦选错了风格，那就好像17世纪中，五月花的落魄船员们闯入了印第安人的部落，可能会是混乱、风格的格格不入。
2
Roy Fielding对风格的定义为：
| “风格是一种用来对架构进行分类和定义它们的公共特征的机制。每一种风格都为组件的交互提供了一种抽象，并且通过忽 略架构中其余部分的偶然性细节来捕获一种交互模式(pattern of interation)的本质特征。” |
这个定义有两个关键词：
- 分类
- 共同特征
这两个关键词皆与抽象有关。
同时，这句话还提及了风格与协作之间的关系，即它是对协作的抽象。架构风格应不涉及详细设计细节，需要找出那些稳定不变的本质特征，且这个特征是与系统的目标与需求是相匹配的。
3
Roy Fielding在论文《架构风格与基于网络的软件架构设计》中写道：
| 网络研究则恰恰相反，集中于系统之间普通的通信行为的细节和提高特殊通信技术的性能，却常常忽略了一个事实，即改变一个应用的交互风格对于性能产生的影响要比改变交互所使用的通信协议更大。 |
这事实上体现了宏观架构与微观架构之间的关系，二者应该保持一致。当然，宏观架构的影响是战略的影响，微观架构的影响是战术的影响，在分而治之的架构原则下，微观架构产生的影响虽然存在，但影响主要还是发生在局部。
4
画出自己的边界线，在边界之内保证风格的一致性。边界外，看待风格的一致性又有另外的标准。
风格对设计起指导作用，并由此驱动对一系列架构属性的满足。架构属性还包括对架构的约束，这些约束一方面能够对设计与实现进行规范，另一方面也可以减少选择项，让设计变得更为简单。
5
| 一种架构风格是一组协作的架构约束，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。 |
将风格视为约束是合理的，但约束更像是对一个封闭的大的集合中的裁剪，规定你不能做什么。风格不仅要规定你不能做什么，还要告诉你应该做什么，它要处理的是一个开放的大的空间，我们需要找到该空间内和谐的内容，并把不和谐的部分剔除出去。剔除出去的这部分内容其实就是违背了架构约束的内容。
架构风格强调的是软件架构的不同方面，一种特定的架构可能有多种架构风格组成。这就体现了架构风格是有层次的。
为了保证架构的一致性，需要在整体层面体现为统一的架构风格，而在不同边界内，展现另外的架构风格。换言之，这种风格的多样性与隔离性，以及风格的层次其实是与架构的层次相对应的。
6
对于设计风格而言，除了要保证风格的一致性外，关键的是要找到一种与正在解决的问题最为匹配的风格。
要了解自己需要解决的问题，同时还要了解不同的架构风格的特征与优缺点，清楚地知道这些架构风格究竟适合处理哪种场景。
【本文为51CTO专栏作者“张逸”原创稿件，转载请联系原作者】
