软件架构（一）软件架构

　　本文主要阐述什么是软件架构、软件架构的重要性、什么时候软件架构尤其重要、什么是推定架构以及软件架构的三种使用方式。

1.什么是软件架构？

架构与详细设计

　　软件系统的设计由开发者的决策与意图组成。设计可以被划分为软件架构和详细设计。

　　专家们一致认同架构的主干，但是在细枝末节上却存在分歧，比如何时终止架构的设计而开始详细的设计。

　　在实践中，也很难将架构和详细设计区分开来。

卡内基·梅隆大学软件工程研究所（SEI）对软件架构的定义：

　　计算系统的软件架构时解释该系统所需的结构体的集合，其中包括：软件元素、元素之间的相互关系，以及二者各自的属性。

　　定义中尤其重要的要素有：元素、关系和属性。架构时解释该系统所需的结构体的集合，而非简简单单地由这些要素组成。

　　虽然这些要素不能完整的描述系统的架构，但是我们也可以使用这些要素对系统进行分析。比如，中国的哪些城市可以乘飞机抵达这类问题，无需中国的完整模型。

　　上面关于架构的定义将架构描述为一组可以帮助我们进行系统推断和分析的要素，这有益于我们专注于架构的目的，但是模糊了架构与详细设计之间的界线。

　　我们可以将架构理解为设计的宏观部分，且并非仅限于系统的宏观层面，即架构并非总是关注于设计的宏观部分，有时设计细节也被归属为架构的内容。

　　那么，该如何判断这部分设计细节是否属于架构呢？这就要看设计细节是否能传达架构师的意图。

　　架构师的某些高层意图或决策会影响到低层的细节，就好像传递意图的链条一样。尽管大多数细节对任何合理的实现保持开放，但对某些细节会有所限制，并可以沿着意图链条回溯到设计者的高层意图。这部分细节就属于架构层面。

2.软件架构的重要性

　　软件架构会影响整个软件系统，所以它的重要性自然不言而喻。

a.架构扮演着系统骨架的角色

　　所有系统都有架构，对于软件系统而言，不存在唯一正确的架构，却存在适合的架构。例如，三层架构使得信息技术系统可以把变更限制在局部范围，并可以处理事务性负载；协作进程架构可以隔离故障，更适合操作系统。

　　但是，架构并非只是那些外部可见的主体部分，还包括某些不可见的部分，通常这部分更重要。例如，锁策略、内存管理策略或集成第三方组件的技术，都可以是架构的一部分，而在运行的系统或源代码中，这些都不可见。

b.架构影响质量属性

　　开发者必须关注软件的功能，比如动画制作软件要可以制作软件。

　　系统还要包含与功能无关的额外需求，称为质量属性需求，这也是开发者必须重视的，比如动画制作软件的运行速度。

　　因此所选择的架构既要能支持所需的功能，也要能促进或抑制诸如安全性或性能等系统质量属性。通常而言，质量属性的演化比功能的演化更能促进系统的演变。

c.架构与功能（基本上）是正交的

　　没有适合于所有功能的架构。但是我们要意识到架构和功能是可以互相混合的。同一功能可以用不同的架构来实现，同样的，同一架构也可以用来实现不同的功能。

　　架构的选择和功能是相互独立的，然而，不合适的架构显然会导致功能和质量属性的实现变得障碍重重。

d.架构是对系统的约束

　　任何系统都有约束，而架构正是对系统恰如其分的约束，这使得系统可以获得所需的质量属性。

　　系统不做什么和做什么同等重要，我们通过施加约束来保证系统不做什么，这样系统可以具备某些特定的质量属性。比如我们对火车施加轨道的约束，火车就不再有随意行驶的灵活性，但获得了速度、安全等优势。

3.什么时候软件架构显得重要？

　　大规模或者高复杂度的系统，要特别重视软件架构。

五种案例：

　　a.小的解空间；

　　b.高的失败风险；

　　c.难以实现的质量属性；

　　d.全新的领域；

　　e.产品线。

4.推定架构

　　推定架构是在特定领域中占据主导地位的架构族。在这些领域工作的开发者可能必须对有别于推定架构的抉择作出解释，却无需证明使用推定架构的合理性。

　　推定架构可以很好地处理领域中常见的风险，所以十分成功。

　　参考架构是描述了针对某一问题在架构层面的解决方案，通常以规格说明书的形式记录下来。

　　参考架构可能成为、也可能永远不会成为推定架构。

5.软件架构的使用方式

　　有时候，即使忽略了软件架构，许多系统仍然能够成功。但重视软件架构，可以排除因为软件架构而导致系统失败的情况。

三种使用软件架构的方式：

a.与架构无关的设计。

　　很少关注架构，要么系统混乱不堪，要么形成并非有意为之的某种特定架构，要么在领域规范的引导下选择了某一推定架构。

b.专注于架构设计

　　谨慎地选择软件架构，以满足系统功能和质量属性。

c.提升架构的设计

　　将系统的某一功能或执行属性提升至架构之中，这时就无需写代码来实现它。