初见软件架构

一、软件架构的定义

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

二、架构介绍的引子

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

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

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

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

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

三、模式对风格

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

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

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

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