初见软件架构

一、软件架构的定义

       软件架构是开发项目和系统的蓝图，定义了必须由设计和实施团队执行的工作任务。架构是系统质量的主要载体，例如性能，可修改性和安全性，如果没有统一的架构愿景，这些都不能实现。架构是用于项目早期分析的工件，以确保设计方法将产生可接受的系统。通过构建有效的体系结构，我们可以识别设计风险并在开发过程的早期缓解它们。

二、架构介绍的引子

       对于开发人员来说，在没有正式架构的情况下就开始对应用程序进行编码是非常普遍。如果没有清晰且定义明确的架构，大多数开发人员和架构师将采用事实上的标准：传统的分层架构模式（也称为n-tier架构），通过将源代码模块分离为包来创建隐式层。 不幸的是，这种做法经常会导致缺乏组织的源代码模块，这些模块缺乏明确的角色，职责和彼此之间的关系。这通常被称为架构的反面模式：大泥球（big ball of mub）。

       缺乏正式架构的应用程序通常紧密耦合，易碎，难以更改且没有清晰的视野或方向。最终结果，如果不完全了解系统中每个组件和模块的内部工作，就很难确定应用程序的体系结构特征。关于部署和维护的基本问题都很难回答：体系结构是否可扩展程序的性能特征是什么程序对更改的响应有多容易程序的部署特征是什么的响应速度如何p>

       架构模式有助于定义应用程序的基本特征和行为。例如，某些架构模式天生地适合于高度可扩展的应用程序，而其他架构模式天生地适合于高度敏捷的应用程序。为了选择满足我们特定业务需求和目标的架构，必须了解每种架构模式的特征，优点和缺点。

       作为架构师，我们必须始终证明自己的架构决策合理，尤其是在选择特定架构模式或方法时。《Software Architecture Patterns》的目的就是为我们提供足够的信息，让我们合理化地选择特定架构模式或方法。

说明：这一部分翻译自《Software Architecture Patterns》by Mark Richards的Introduction部分，版本信息：2017-06-22，第三次发布。

三、模式对风格

       在架构模式之上还有架构风格这一层概念。

       区分架构模式和架构风格是有好处的。模式针对的层面比风格针对的层面要小一些。模式在设计中随处可见，在同一个设计中，可以出现多种模式。相反，一个系统通常只有一个主导的架构风格。

       架构风格和架构模式之间的区别有时并非那样清晰，肯定可以找到一些两者难以区分的例子。系统的规模越大，所谓“系统的系统”就很常见，即独立的系统会成为更大系统的一个组成部分。原先独立的系统有自己的架构风格，但现在却从属于一个更大规模系统的架构风格，在这种情况下，自己原先的架构风格不是很有可能降成为一种架构模式吗，不要担心应该把某些东西归类为一种术语、一种设计模式、一种架构模式，还是一种架构风格，为了保险起见，我们可以把它们都称为模式，或许，我们还可以把架构模式和架构风格当做同义词。

说明：这一部分摘自《恰如其分的软件架构-风险驱动的设计方法》2013年9月第1版的14.4章节。