什么是“好的”软件架构

 

本文来自于：Software Architecture in Practice 3rd Edition--Addison-Wesley

Len Bass

Paul Clements

Rick Kazman

1.4 What Makes a “Good” architecture?

 

这几天在做一个软件架构的短视频，系统的看了一些软件架构的知识。和对任何概念的认识一样，学习软件架构也同样需要明确定义和评判标准。所以，我们得搞明白两件事情

1. 软件架构的定义，即软件架构是什么
2. 软件架构的评判标准，即什么才是好的架构

今天我们先不看定义，只看“软件架构的评判标准，即什么才是好的架构”。网上搜一下“软件架构”，你会得到无数的定义和评判标准。不过，我们今天不关注“群众的呼声”，而是看一下业界大佬的观点，即：Software Architecture in Practice 3rd Edition中的观点。

 

正文开始

 

什么才是好的架构

没有内在就好或坏的架构。架构或多或少都满足了某种目的。三层结构的SOA架构可能是大型企业基于Web的B2B系统的首选，但，这种架构对于航空应用来说却是完全错误的。精心设计地以实现高可修改性(high modifability)为目的的架构对于用完就扔的原型应用来说就毫无意义（反之亦然！）。本书传达的信息之一就是，架构实际上是可以被评估的(evaluated)--这也是关注架构所带来的巨大收益中的一个，但，只有在有明确目标的上下文中才能被评估。

尽管如此，在设计大多数的架构时，依然应该遵循一些经验法则。不满足其中的某一个法则，并不意味着该架构一定具有着致命的缺陷，但至少它应该作为需要进行研究的警告信号。

我们把我们的观察结果分为两个类别：过程建议(process recommendations)和产品（或结构）建议(production/structural recommendations)。

我们的过程建议(process recommendations)如下：

1. 架构设计应该由一位架构师来完成，或者由一小组架构师来完成，这一小组架构师由一个被认可的technical leader所领导。这使得架构具有概念完整性和技术一致性。该建议既适用于敏捷项目和开源项目，也适用于“传统”项目。架构师与开发团队之间应该保持紧密联系，以避免不切实际的象牙塔(ivory tower)设计。
2. 架构师（或架构团队）应该始终把架构建立在 划分了优先级的 定义明确的 质量属性要求(quality attribute requirements)之上，这会时时提醒架构师需要权衡。功能不那么重要。
3. 架构应该使用视图的方式记录。视图应该解决最重要的利益相关者(stakeholder)的关注点，以支持项目的时间表。这意味着一开始可能需要最少的文档，后期再补充详细内容。关注点通常与系统的构建、分析、维护，以及对新stakeholder进行该系统的培训 有关。
4. 应该评估架构交付系统最重要的质量属性(quality attributes)的能力。这应该发生在生命周期的早期，这时得到的收益最大，在适当情况下需要重复评估，以确保对架构（或架构的预期环境）的改变不会导致设计过时。
5. 架构应该能够被增量实现(incremental implementation)，以避免必须一次集成所有内容（这几乎总是行不通的）以及尽早发现问题。 实现该目的的一种方法是创建一个“skeletal system”，在“skeletal system”中实现通信链路可运行(the communication paths are exercised)，但起初只有最少的功能。该“skeletal system”可被用以逐步“增长”系统，在必要时进行重构。

 

我们产品（或结构）建议(production/structural recommendations)如下：

1. 架构应具有定义明确的模块(module)，模块的功能职责是根据“信息隐藏和关注点分离(information hiding and separation of concern)的原则”来分配的。信息隐藏模块应该封装可能发生变化的部分，从而使软件免受这些变化的影响。每个模块应具有定义明确的接口，对于使用该模块的其他软件的来说，这些接口封装或“隐藏”了这些可变部分。这些接口应允许它们各自的开发团队在很大程度上独立于彼此工作。
2. 除非您的需求是前所未有的（存在这种可能性，但，不太可能发生），否则您的质量属性(quality attribute)应使用 针对每个质量属性的 well-known的 架构模式和策略(tactic)来实现（在第13章进行了介绍）。
3. 架构永远不应依赖于某个特定版本的商业产品或工具。如果必须的话，应该对架构进行结构设计，使得更改依赖到某个其他版本时能直接且代价较小
4. 生产数据的模块和消费数据的模块应该分开。这样能增加可修改性(modifability)，因为改变经常被限制在生产方或消费方。如果添加了新数据，则生产方和消费方都必须进行更改，但是这种分离允许分阶段（增量）升级。
5. 不要期望模块(module)和组件(component)之间一一对应。例如，在并发系统中，可能有多个组件实例并行运行，其中每个组件都是从同一模块构建而来。对于具有多个并发线程的系统，每个线程可以使用来自多个组件的服务，每个组件都是从不同的模块构建而来。
6. 每个进程都应该是可写的，以便可以修改分配给其的处理器，甚至在运行时修改分配给其的处理器
7. 架构应具有少量的组件交互方式。 也就是说，系统应该始终以相同的方式执行相同的事情。 这样有助于增加可理解性，减少开发时间，增加可靠性，并增强可修改性。
8. 架构应包含一组特定（且较小）的资源争用区域，并明确规定和维护其解决方案。例如，如果网络利用率是一个值得关注的点，则架构师应为每个开发团队制定（并执行）可以使得网络流量最小化的方案指南； 如果性能是关注点，那么架构师应该为主要线程制定（并执行）时间预算方案指南

 

完