1.1 为什么需要软件架构

1.1.1 什么是软件架构

对于软件架构，不同的人有不同的理解，不同的组织有不同的定义。如维基百科上说：

软件架构是指软件系统的高级结构，以及创建这种结构和系统的约束。每个结构包括软件元素、元素之间的关系，以及元素和关系的属性。软件系统的架构是一种隐喻，类似于建筑物的体系结构。它作为系统和开发项目的蓝图，列出了设计团队必须执行的任务。

而在IEEE（14712000）中，架构是指体现在它的组件中的一个系统的基本组织、组织之间的关系、组织与环境的关系及指导其设计和发展的原则。

又或者相似的其他定义，无一不在强调设计架构的整体及内部各个部分的关系。与此同时，还涉及实施过程中的原则和相关的设计实践。软件开发的过程就好比盖房子：

◎ 如果不能完成地基的建设，那么房子就无法继续往上盖。

◎ 开始盖房子时，便是在实施对应的架构。若地基有问题，房子就难以长期存在。

◎ 在浇筑钢筋水泥的过程中，若不注意，房屋就可能歪歪扭扭。

◎ 虽然房子盖好了，但是不注意后期的保养和维护，仍然会出现问题。

盖房子和软件开发是相似的，需要规划、设计、实施，而后才能使用。盖房子，最先设计的也是建筑的架构，有了建筑的蓝图，还需要考虑美观、实用、坚固等要素，从各种各样的材料中选择合适的，完成这一系列决策才能进入实施阶段。在实施的时候，还需要严格按照建筑的蓝图来进行施工，并保证施工的质量，才能造出所需的建筑。

对于软件开发来说也是相似的。最初，设计出软件的总体架构蓝图，思考各个模块之间的关系，实施一系列相关的架构决策。然后，选择软件开发所需要的一系列技术栈、框架等，讨论关于应用的上线、部署等流程问题。最后，才能进入软件的开发阶段。在开发的过程中，还需要保证软件的质量，才能设计出符合要求的系统。

而无论是建造房屋，还是开发软件架构，其中的一个重中之重的步骤便是结构设计。对于房屋来说是建筑结构，对于软件来说则是软件架构。

1.1.2 开发人员需要怎样的软件架构

不以实现为目的的架构，都是无意义的。因此，我们对系统架构的基本判断如下：

◎ 一个无法上线的应用架构，算不上好的软件架构。

◎ 一个没有人能完成开发的软件架构，算不上具有可行性的软件架构。

◎ 一个在现有的技术上不可行的架构，算不上合理的软件架构。

所以，一旦我们谈及软件架构，需要讨论的第一个重点便是因地制宜。在BAT这一量级的公司里，他们实施的架构往往无法在小公司里照搬。这一量级的组织拥有大量的资源、基础设施，与之相匹配的优秀人才。若想实施相似的架构，小公司所需要的则是在时间上的长时间投入，或者有强力的技术人员，才能驱使系统往这个方面靠拢。其所依靠的是循序渐进的方式，只有这样才能完成架构目标。

除此，谈及软件架构的时候，还得有这么一些人——他们能按时、高质量（或者说有质量）地完成系统的设计。只凭一系列软件的架构蓝图，没有对应的实施者、维护者，那么系统就可能不会以预计的方式来构建；只凭一系列的架构蓝图，没有相应的实施规范和原则，便无法按我们预期的方式来实施项目。

为此，我们期望的软件架构，应该是贯穿在它被应用的生命周期里的，应该包含以下的内容：

◎ 系统间关系。明确地指出该系统与其他系统之间的关系，是调用关系，还是依赖关系等。

◎ 系统内关系。系统内各子系统之间的关系，如前端应用与后端应用，以怎样的方式通信，需要怎样的通信机制。

◎ 应用内架构。包含应用相关的框架、组件，并清楚地表示出它们之间的关系。

◎ 规范和原则。用于指导项目中的开发人员，编写出符合需求的代码，以构建出设计中的架构。

对于瀑布型项目而言，它还包含类级别的架构，即一个类应该提供怎样的接口，存在怎样的继承关系。而对于敏捷型项目而言，它们则会在进入项目后才完成。这部分的内容，偏向于系统的详细设计。同理于前端应用，我们决定开发、使用哪些UI组件，便属于系统的抽象架构部分。而关于这个组件提供的接口，则偏向于组件的详细设计，但是它也属于要考虑的架构范围——但并非是必须考虑的范围。