What the hell is Software Architecture
作者 Jan Stenberg ，译者 [njluz]
自动九十年代开始，出现了很多软件架构的定义，但是大部分定义不够清晰。最终，从这些架构的定义中产生了一个大家能认同的标准定义：架构就是一组互相协作的组件。在我看来，这个观点过于简单了。现在大部分大学相关的教学内容也沿用了相同的定义。但是从工程角度看，这个定义毫无用处。
我们应该从架构属性角度继续思考这个话题，而不是继续再提出新的软件架构的定义。
一、 软件架构既可以看成是一件物件也可以看作一个过程，过程包含了一系列战略决策，架构可以看作是这个过程的结果。软件架构的目标是去创建一个用于实现规格的骨干（backbone）。注意，在这里我们并不假定采用一个特定的软件开发模式，例如精益或者是敏捷开发模式。
-
注1:战略决策是指那些影响整个系统架构或设计结果的需求或外力 ，这些架构或设计通常跟系统其它部分的架构耦合在一起，使得变更会非常困难或代价高昂。例子可以包括系统必须具备的功能，性能或安全性的要求，为了支持可修改性引入的插件式的基础架构，系统硬件的约束。
-
注2：所有的架构设计决策必须从需求和业务目标出发。简而言之，没好的理由就不做决策。
二、 架构设计不只是发生在系统建设阶段，而是会延伸到系统整个的生命周期。架构设计开始于项目的初始计划和需求调研，截止于基于这套架构的系统到达下线。在此期间包括多个重要的阶段：建设、运维和演进。
三、 一个天真的感觉是，每一个软件集约型系统都会展现了一种软件架构，哪怕是这个系统在创建时候采用的是一种非系统性或者无目标的方式。例如采用了临时决策方式。我们希望获得的是一个由明确定义、已确定优先顺序与相关性的需求及风险所驱动的系统化架构设计。有时候，我们需要去使用（重用）一个我们对其架构一无所知或知之甚少的系统的部分甚至全部。在这种情况下，我们需要采用软件考古的方法去获取其隐藏的软件架构，并使它们显性化。
四、 软件品质有有两种类型：外部品质和内部品质。外部品质定义了品质属性所需的可视行为。内部品质是被开发者或测试者所采纳的如简化和富表现力的架构件的宜居性（habitability）属性。
- 注：架构宜居性（habitability）的要求会导致对软件架构的设计产生约束，软件会被分为一些有层次的实体，例如系统，子系统，组件。这些实体应该遵循单一职责的原则。相应的，好的设计和实现的职责也是要通过提炼和扩展这些抽象，提供可执行的架构构件。
五、 必须有一套统一的指导方针和工具用于能指导架构设计。这是达成高品质架构必不可少的条件。没有这些指导方针，系统将会因为存在多种风格，方言，模式，概念，技术，范例，惯例而变得臃肿和过载，进而减低系统架构的内部品质。
- 注：在避免偶发复杂性的时候一个主要的挑战是去驯服系统内在的复杂性。偶发复杂性可能是因为使用了一个错误方案，或者用错一个正确的方案。
六、 软件架构作为一种物件，就是在同其他干系人进行设计决策沟通的结果。因此架构决策必须用一种可理解的方式显式表达出来。软件架构的各种构件应该根据不同的利益相关角色责任充分的描述出来。软件架构的文档必须提供一系列一致且完备的架构视图。
-
注1：软件架构是一件物件也是一个过程，架构文档包括一系列的设计决策和设计原理，这些原理用于描述架构视图和流程，这些流程可以让需求和决策具有可跟踪性。
-
注2：软件架构是设计和实现的基础。它为获得基础代码定义了一个初始的骨架。这也是为什么架构宜居性（habitability）是最重要的原因。
七、 软件架构不是一座孤岛，软件架构必须包含问题域和解决方案域。因而软件架构必须与其环境保持分离，分离的同时需要考虑清楚两者之间的接口和交互行为，否则就会构建一个不合适的架构。这种情况下，使用一个上下文的视图和用例视图可以帮助解决这个问题。
八、 软件架构必须同时覆盖问题域和解决方案域。因而一个多层设计并不算是一个架构。应该避免为这两个领域使用一种单体庞大的设计，两个领域应该采用分层结构去构建各自的子领域和相互关系。创建软件架构的活动行为应该分别由这些子领域去驱动，而不是由直线集权型的组织去驱动。换句话说，注意康威定理。
九、 软件架构没有必要被约束在一个系统上使用。软件架构可以针对一个特定的问题域，为一组系统定义一个公用的基础架构。在这种复用的场景中，共性差异的分析是需要的，在设计和实现启动之前，需要为这个特定场景构建一个公共基础的架构。
举例：产品线架构，生态系统架构，平台/基础设施架构，公共库架构。
- 注：这也就是参考架构和产品线架构的含义。
十、 架构设计必须遵循测试驱动的方法论，确保架构是可以被测试的。测试可以帮助在架构设计过程中，发现质量问题和设计缺陷方面的相关信息。测试结果可以包括了架构定量和定性方面的视图。
软件架构
最后，我还是忍不住要总结另外一个软件架构的定义：
- 是一个流程，也就是通过一系列经过策划的战略设计决策， 把规格说明和业务目标映射到架构设计上。
- 是一个物件，也就是通过通过架构设计流程产生一系列的视图，这些视图描述软件不同的利益相关角色关切。
软件架构的主要挑战是：有不同的方法去创建一个好的软件架构，但是却有无穷的方法去创建一个坏的。
Some may wonder why software architecture should be considered a process as well.
It is insufficient to obtain some architecture views, i.e. the What. In addition, we might need information how the architecture has been created and why it is as it is, i.e. the How and the Why. This is not essential for some stakeholders such as users, but it provides relevant information to developers, customer service, and testers.
One notable example is the detection of design flaws. When we encounter a flaw in our system, we'd like to know when the design flaw has entered the "crime scene" and what other decisions depend on this flawed decision. This gives us traceability and the possibility to rollback in a systematic way. Likewise, process knowledge is important for architecture reviews.
在与InfoQ的一次访谈中，Stefan Tilkov认为Stal的文章写得很好。Tilkov注意到他可以不将架构视为一套独立于开发的流程，他将架构看作是项目的一个功能和组织的大小。他也提到与将架构看成“系统的描述或系统想要的形式”不同，他觉得架构是“系统所拥有的某种东西”，无论架构是如何被创建的。
网友评论