编写架构设计文档

软件架构

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构描述了组成软件系统的组件，组件之间的关系，组件及这些关系的属性。

大型软件一般都是应对复杂的需求，同时也需要更多人员的参与， 通过架构设计，可以将复杂的业务需求，拆分到多个架构单元中，通过他们之间协作来完成这项工作。 架构设计完成对各架构单元的功能定位， 明确各个单元间通讯规范及单元内部的开发规范，使得相关开发人员不必过多得了解复杂的业务流程， 更多的精力用于提高软件质量和开发效率上。

常用软件架构

分层架构

最常见的架构模式是分层架构模式，也称为 n 层架构模式。 分层架构模式与大多数公司中的传统 IT 通信和组织结构紧密匹配，这使其成为大多数业务应用程序开发工作的自然选择。

图 1-1

分层架构模式中的组件被组织为水平层，每一层都有清晰的角色和分工。 尽管分层体系结构模式没有指定模式中必须存在的层的数量和类型，但是大多数分层体系结构都由四个标准层组成：表示层，业务层，持久性层和数据库层（图 1-1）。对于较大且更复杂的业务应用程序可能包含五层或更多层。

事件驱动架构

事件驱动的体系结构由高度分离的单用途事件处理组件组成，这些组件异步接收和处理事件，下面是通过事件分发器进行事件分发模式。

图2-1

分发器模式有四种主要类型的体系结构组件：事件队列，事件分发器，事件通道和事件处理器。事件流从客户端将事件发送到事件队列开始，该事件队列用于将事件传输到事件分发器。事件分发器接收初始事件，并通过将其他异步事件发送到事件通道以执行过程的每个步骤来协调该事件。侦听事件通道的事件处理器通过时间通道接收事件，并执行特定的业务逻辑来处理事件。

当处理流程简单时， 也可以不使用分发器，事件处理器通过指定的事件通道接收发送事件。

图2-2

微内核架构

微内核架构模式（有时称为插件架构模式）是用于实现基于产品的应用程序的自然模式。 其他应用程序功能作为插件添加到核心应用程序，从而提供可扩展性以及功能分离和隔离。

图片3-1

微内核架构模式包括两种类型的架构组件：核心系统和插件模块。应用程序逻辑在独立的插件模块和基本核心系统之间划分，提供应用程序功能和自定义处理逻辑的可扩展性，灵活性和隔离性。图 3-1 说明了基本的微内核架构模式。传统上，微内核架构模式的核心系统仅包含使系统运行所需的最小功能。 插件之间的通信减至最少，以避免依赖性问题，这一点很重要。

微服务架构

微服务架构是面向服务架构 SOA 的变体，服务间松散耦合， 微服务中服务是细粒度的， 协议也是轻量级的。

图4-1

这种架构的重要的概念就是服务组件， 服务组件一般由实现单一功能（例如，提供特定城市或城镇的天气）或大型业务应用程序的独立部分（例如，股票交易位置或确定自动保险费率）的一个模块或多个模块组成。 架构中的所有组件都完全相互分离，并可以通过某种远程访问协议实现分布式访问和调用。

基于空间的架构（云架构）

基于空间体系结构专门专门用于解决可伸缩性和并行性的问题， 对于不可预测的并发用户量，可以进行很好的处理。此体系结构模式中有两个主要组件：处理单元和虚拟化中间件。图 5-1 说明了基本的基于空间的架构模式及其主要架构组件。

图5-1

基于空间的模式（有时也称为云架构模式）使限制应用程序扩展的因素最小化。该模式的名称来自元组空间的概念，即分布式共享内存的概念。通过消除中央数据库约束并使用复制的内存中数据网格来实现高可伸缩性。应用程序数据将保留在内存中，并在所有活动处理单元之间复制。随着用户负载的增加和减少，处理单元可以动态启动和关闭，从而解决了可变的可伸缩性。

O'Reilly 出版的 《Software Architecture Patterns》 （PDF）

架构师的职责和能力

对于大型软件，架构师这个角色是非常重要的， 需要精通技术：既要有深度，能够解决软件构建过程中的难题，构建自己的影响力，也要有广度，更够的选对的技术工具，组件从而事半功倍，也要熟悉业务， 能够将业务需求转化为清晰的系统数据流。 通常，架构师的职责和能力如下：

职责

1. 编写架构设计文档

2. 开发编程框架

3. 重构软件代码

4. 设计系统架构

5. 进行技术选型，解决技术应用中的问题

6. 优化系统性能

7. 保障系统安全与高可用

8. 大数据应用

9. 技术创新

10. 沟通管理

能力

1. 编程能力

2. 基础技术掌握能力

3. 常用技术产品的理解与应用能力

4. 性能优化与分析故障的能力

5. 常用架构模式和框架利己的与应用能力

6. 建模以及设计文档的方法和能力

7. 业务理解与功能模块及非功能模块拆分能力

8. 快速学习能力

9. 沟通与领导能力

软件架构文档

软件架构文档

架构文档结构如下:

1. 设计概述

1.1 功能概述

1.2 非功能概述

2. 系统部署图与整体设计

2.1 系统部署 (系统部署图)

2.2 功能流程 (系统序列图)

3. 系统设计

3.1 子系统构成 (子系统组件图)

3.1.1 组件 1 设计

3.1.1.1 场景 A 组件序列图

3.1.1.2 场景 A 组件活动图

3.1.2 组件 2 设计

3.1.2.1 场景 A 组件序列图

3.1.2.2 场景 A 组件活动图

软件架构建模

模型是系统的完整的抽象, 人们对某领域特定问题的求解和解决方案, 对他们的理解和认识都蕴含在模型中, 通常开发一个计算机系统是为了解决某一个领域特定问题, 问题的求解过程就是从领域问题到计算及系统的映射.

软件架构视图

4+1 架构视图:

• 逻辑视图: 设计的对象模型

• 过程视图:并发和同步特征

• 物理视图: 反映部署特征

• 开发视图:开发环境中软件的静态组织.

• 场景视图:描述用例场景:

通过场景视图描述业务场景, 通过需求分析人员的分析后,抽象为逻辑模型, 将一个一个业务逻辑进行归类, 通过各个子系统或组件之前完成, 通过过程视图将一个具体的业务功能转化为在各个子模块或组件中流流转的数据流, 开发人员和运维人员分别通过开发视图和物理视图完成软件的开发和部署.

建模工具 UML

静态模型

• 用例图

用于描述系统功能需求, 再宏观上给出模型总体轮廓 ,通过典型的而用力分析使开发者可以有效的了解用户需求.

• 类图

类图(class diagram)描述系统中的对象类型，以及存在于它们之间的各种静态关系。类图也展示类的性质和操作，以及应用于对象连接方式的约束

• 对象图

对象图（object diagram）是某时间点上的对象在系统中的快照。因为它展示实例而不是类，对象图经常被称为实例图

• 包图:

包是一种分组构造，它允许你选择 UML 里的任何构造，把它的元素组织在一起，成为更高级别的单元。

• 组件图

系统分解成组件并要展示它们通过接口的相互关系时，或者把组件分解为更低级别的结构时，使用组件图。

• 部署图

部署图展示系统的物理布局，揭示哪个软件运行在哪个硬件上

动态模型

• 状态图

状态图(state diagram); 描述了对象,子系统,系统的生命周期.

• 活动图

活动图(activity diagram)是描述过程逻辑、业务流程和工作流的技术

• 时序图

时序图(sequence diagram)描述对象组在某些行为中如何协作。UML 定义了若干形式的交互图

• 合作图

合作图(Colaboration Diagram),也称协作图,用于描述相互合作的对象间的交互关系和链接关系.

参考引用

The Unified Modeling Language -https://www.uml-diagrams.org/ 比较全面讲解及相关例子

软件架构入门 - http://www.ruanyifeng.com/blog/2016/09/software-architecture.html 阮一峰网络日志

架构师训练营作业-李智慧老师相关讲义

Photo by Rodrigo Souza from Pexels