Summary date 2019-12-8

Summary date 2019-12-8

软件的架构

什么是软件架构以及为何我们需要它?
就如同其他复杂结构一样，软件必须要建构在一个坚实的基础之上。没有考虑到关键场景，没有针对常见问题的设计，或者没有考虑一些重要决定带来的长期结果，就会将你的软件应用程序置于危险之中。代码没有架构，就如同花园中的常青藤，会变得很难维护，添加新特性也困难。

软件架构是一个技术蓝图，诠释了在优化诸如软件性能，安全性以及可管理性等常见的属性时候系统是如何由子系统（模块）构建的。

Philippe Kruchten, Grady Booch, Kurt Bittner以及Rich Reitman在Mary Shaw and David Garlan (Shaw and Garlan 1996)的成果基础上延伸并提炼出了对软件架构的定义。他们是这么定义的:

软件架构包含关于一个软件系统组织结构方面的诸多重要决策，包括如何选择系统构成的结构元素以及结构；那些元素间协作的特定行为；这些结构以及行为元素如何组成一个更大的子系统；指引这个组织结构的架构风格。软件架构还包含功能性，可用性，适用性，软件性能，重用性，经济以及技术方面的限制，折中方案以及美学等诸多方面的考量。

在Patterns of Enterprise Application Architecture 中，Martin Fowler 概括了一些解释架构是经常提到的主题。他认为这些主题是：

一个系统在最高级别上分解为多个局部；不易变化的决定；一个系统可以有多个架构；明显架构化的东西也会在一个系统的生命周期里变化；最后，架构归结为任何重要的东西。

在 Software Architecture in Practice (2nd edition )中，Bass, Clements 和 Kazman 这样定义架构：

一个程序或计算机系统的软件架构是指系统的一个结构或多个结构，它们组成软件元素，元素的外部可见性，元素间的关系。架构关心公共接口；元素的私有细节——内部实现的细节——不是架构。

架构的目标是识别出影响应用结构的需求。优秀的架构能减低构建一个技术解决方案的业务风险。优秀的设计是足够灵活的，可以应对随时变化的硬件与软件技术，以及用户场景与需求。

软件架构提供了一些益处，包括：

更高的生产效率。 结构确定了，那就更容易想已有的软件添加新个性，而且每一处新代码的位置都是事先知道的。

更好的代码可维护性。 代码结构可见和已知，那就更容易维护已有的软件，所以也更容易找到 bug 和异常现象。

更高的适应性。 软件架构事先考虑到清晰的分离，那就更容易完成诸如换一个前端，添加业务规则引擎等新技术特性。

宣扬不可知论。 最后，不过不是必然，软件架构能使你根据你当前的结构看到行业里大肆宣扬和时髦的东西，去适应这些大肆宣扬和时髦的东西。

软件架构模式和风格
客户端/服务端 架构
客户端/服务端 是由两部分组成的软件架构模型，通过计算机网络——或在同一台计算机上——相互通讯的客户端系统和服务端系统。一个客户端-服务端应用是由客户端和服务端软件组成的分布式系统。客户端-服务端应用提供了一种分担负载的好方法。客户端进程总是启动一个到服务端的连接，而服务端进程则总是等待来自任何客户端的请求。客户端-服务端架构有时也角度奥两层架构。

基于组件的架构
基于组件的架构关注于设计的分解，即设计成单独的功能性或逻辑性组件来表示定义明确、包含方法、事件与属性的通信接口。它提供了更高层次的抽象并将问题分解为与组件相关的子问题。

基于组件的架构的首要目的是确保组件的复用性。组件将一个软件元素的功能与行为封装到一个可重用的、独立部署的可执行单元。

下面是用UML 2.0表示的两个组件。负责处理用户订单的checkout组件需要通过CardProcessing组件从用户的信用卡/借记卡中扣费(即后者提供的功能)。

领域驱动设计
领域驱动设计(DDD)是创建满足核心业务目标的高质量软件的方法。它强调领域专家、开发者、UX(用户体验)设计师及其他相关人员间的合作，以创建一个能反映业务需求的领域模型。这包括通用术语(也称为通用语言)的协商、业务实体的指定及其行为与联系，并以一种能够生成整洁且模块化的实现方法进行组织。

策略领域驱动设计模式及其间的关系

分层架构
分层架构专注于将应用程序中的相关功能组合到不同的层级中，层级间呈现出垂直层叠的结构。每一层中的功能都同一个通用和角色或者职责相关。层级间的通信是明晰的，而且是松耦合的。将你的应用程序分出层级来非常有助于对关注点分离策略的支持，而这回头就支持了灵活性和可维护性。

消息总线架构
消息总线架构描述了描述了一个使用软件系统的原则，那就是能使用一个或者更多的通信信道来接收和发送消息，那样应用程序无需知道每个信道的特定的细节就能实现交互。这是一种设计应用程序的风格，采用这种风格之后应用程序间的交互就由公共总线上消息的传递来完成(这种传递经常是异步的) 。消息总线架构最常用的实现不是使用的消息路由，就是发布/订阅模式，并且经常使用一个诸如消息队列这样的消息系统来实现。

N层/3层架构
N层/3层架构描述是将功能大致像分层风格的架构那样分隔成几段，而让每一段都成为可以被放到一个物理上分离的计算机上的层。它们是通过面向组件的方法被发展而来的，一般通信是用的特定于平台的方法，而不是基于消息的方式。

面向对象的架构
面向对象的架构是一种基于责任分解的设计范式，即将系统分解为独立可复用的对象，每个对象包含了与自身相关的数据与行为。面向对象设计将系统看作一系列相互协作的对象，而不是一组程序或处理指令。对象间相互分离、独立且耦合松散；它们通过接口调用或处理其他对象内的属性，并通过消息的发送与接收在接口上进行通信。

洋葱架构
洋葱架构是由 Jeffrey Palermo 提出的，它类似于 Alistair Cockburn 提出的六边形架构(Hexagonal Architecture)。

该架构的提出最初是为了避免在 N 层架构中各层间的依赖关系。它通过将所有基础服务（包括数据库）移出问题域来实现。将此理论实施到 N 层架构意味着要将依赖流反转，从而将业务逻辑独立出来。

这个理论生成了一个新的模型，在这个模型中业务逻辑处于架构的中心，其他层围绕在它周围形成同心环，就像一个洋葱一样。

软件开发流程
计算机软件的开发流程按顺序可以划分为：可行性分析；需求分析；设计（概要、详细）；开发阶段；测试阶段；运行维护。

一、可行性分析

1、公司要对项目确定项目经理，由公司和项目经理确定项目的主要组成人员，包括：产品经理、架构工程师、UI工程师、开发工程师、测试工程师等。

2、项目经理组织业务人员、产品经理等对项目的场景、效益、技术、管理等各方面进行调研和可行性分析，并把存在的问题及时与客户进行交流，输出项目的调研报告、可行性分析报告等。

3、若经过可行性分析，项目组能在规定的时间和资源范围内完成该项目，则出成本和资源使用计划书，并把相关资料提交给公司和客户，可以着手准备下一步的工作；若经过调研和分析，项目组无法在规定的时间和资源范围内完成该项目，则把相关依据提交给公司和客户，协调对资源进行调整，调整完成后进入下一步的工作。

二、需求分析

1、产品经理要进行需求采集、需求分析和需求确认这几方面的工作，然后输出需求分析文档和产品原型图，文档和产品原型图要及时与客户进行沟通，不符合客户要求的要及时修改，并做好修改记录。

2、确定原型图后，产品经理可输出业务流程图和页面跳转流程图，并与客户做开发前的需求确认工作。

3、产品经理输出培训文档，对项目组的人员进行需求讲解。

4、架构工程师根据需求对整个软件的体系架构和关键模块进行分析设计。

5、架构工程师和开发工程师根据需求和架构设计，制定项目开发计划和模块分解表。

6、UI工程师根据需求、原型图和开发计划，制定UI设计计划，以保证及时完成各页面UI设计工作。

三、概要设计

1、架构工程师根据需求和体系架构对软件运行环境、模块编码、流程控制、接口、运行控制和数据结构进行设计，并输出概要设计文档。

2、开发工程师根据概要设计文档设计数据库结构，并输出数据库设计说明书。

3、UI工程师根据需求分析、原型图和UI设计计划，制定UI设计规范，并输出文档。

四、详细设计

1、UI工程师根据产品原型图、UI设计规范，设计软件界面效果图。

2、开发工程师确定每个模块的算法，写出每个模块详细的过程描述。

3、开发工程师确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及模块输入数据、输出数据及局部数据的全部细节，并形成详细设计文档。

4、为每一个模块设计出一组测试用例，以便在开发阶段对模块代码进行预定的测试。

5、开发工程师根据数据库设计说明书进行数据库物理设计，设计数据库表、字段、描述等，统一命名规则。

五、开发阶段

1、开发工程师根据产品原型图、UI效果图、详细设计文档，选择合适的开发环境、开发工具、开发语言等，统一每个模块、页面的命名规范。

2、开发工程师搭建软件框架，进行模块编码。

3、开发工程师对自己开发出来的模块要进行测试用例自测或是开发人员之间互相测试，排除出现的问题。

4、开发工程师要养成良好的开发习惯，编写好开发说明文档，做好代码功能注释、使代码的可读性更强。

六、测试阶段

1、测试工程师根据开发阶段形成的说明文档和程序架构，设计测试用例，测试用例不仅要考虑合理的输入数据，也要考虑不合理的输入数据。

2、测试工程师对程序进行单元测试、集成测试、系统测试，检查是否正确完成规定的功能，把出现的编码错误、算法错误整理成文档，并提交给开发工程师。

3、开发工程师根据测试工程师提交的测试文档，对出现的错误进行修改，再交由测试工程师测试，通过后完成。

4、产品经理、测试工程师安排软件测试版给普通用户试用，并收集用户使用意见和问题，把软件出现的错误交由开发工程师进行修改，这时候软件的错误数量已经很少，对软件的改动不大。

5、产品经理、测试工程师完成软件各端口的操作手册、软件使用手册等。

七、运行维护

1、项目经理组织客户、业务人员、产品经理、开发工程师进行软件验收、上线运行工作。

2、产品经理对软件使用人员进行培训。

3、开发工程师定时对软件进行各项维护，对使用过程中出现的问题要及时进行修改。