架构师之路 — 软件架构 — 架构软件的过程

目录

前言

一个软件架构的诞生始于目标的确立，然后是对需求的刻画，继而是落地方法的抉择。

1、建模

百度百科定义：

建模就是建立模型，为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

《Thinking in UML》定义：

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

现实世界到软件世界的过程，就是一个建模的过程。从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型。通过不断的抽象去粗取精，形成对现实世界的层层抽象，所以架构软件的核心其实就是建模。

业务建模

理解业务本身，需要对行业背景有深入的了解，最终才能够产出 “业务核心流程图” 和 “业务功能模块图”。

概念建模

在业务建模后就是概念建模，作为架构设计的输入，这个阶段就需要对核心业务的充分理解，同时在基础性和通用性方面的功能也需要同时考虑，这个阶段需要大量的业务专家和各个领域的科学家通力协作，保证对系统的理解没有偏差。

系统建模

系统建模一定是建立在业务建模基础上的，完成业务需求到系统模型之间的映射。这其中涉及业务功能到系统能力、业务流程到数据流程的映射；系统建模更强调职责、依赖、约束关系，用于指导研发的落地实现。

2、抽象

百度百科定义：

从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象。

抽象纵向层次

抽象纵向层次，例如下图中关于网络模型的抽象，关于操作系统内核的抽象。

抽象纵向层次划分的依据和原则如下。

依据：

1. 以抽象角度分层，可能一层是多角度的聚合。
2. 面对变化分层，用层次隔离变化。

原则：

• 公用的往下走。
• 个性的往上走。
• 下层可以独立于上层存在。
• 控制下层的变化。

抽象横向边界

如果说层次考虑的是纵向维度的表达（分层次），那么边界考虑的是横向维度的表达（分功能模块）。如何确定边界，一个总的原则是按照职责进行划分，这里的职责其实也就是分工。

一旦职责确定，在做建模分析时就不需要把整个业务大局放进来从头到尾去分析一遍，只需要考虑当前分工下的上游和下游即可，这样的信息量大大减少，自然的，面对的领域复杂度也会降低到一定程度。

抽象分界的依据就是要确定：

• 核心实体。
• 核心实体业务流程。
• 核心实体生命周期。

抽象的评估原则

高内聚，低耦合是评估一个抽象的基本原则。

• 内聚：是一个模块内部各成分之间相关联程度的度量。
• 耦合：是软件结构中各模块之间相互连接的一种度量。

抽象的方法论

抽象有 2 种方法，一种是自顶向下，另一种是自底向上。

• 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程。
• 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程。

下面这张图来自于《Thinking in UML》：

3、描述

架构图描述

UML 工具

• 静态结构图（Structural Diagrams）：通过对象、属性、操作和关系等方式，强调系统的静态结构，其中最常见的类型包括类图（Class Diagram）、组件图（Component Diagram）和部署图（Deployment Diagram）；

• 动态行为图（Behavioral Diagrams）：通过展示对象之间的协作关系以及对象内部的状态改变，强调系统的动态行为，其中最常见的类型包括用例图（Use Case Diagram）、活动图（Activity Diagram）、时序图（Sequence Diagram）和状态机图（State Machine Diagram）。

4+1 View Model

场景（Scenarios）

通过一小组用例或场景来描述架构，包括系统中各种对象和进程之间的交互时序，也被称为 “用例视图”。这些场景会被用于识别架构元素（architectural elements）以及阐述和验证整个架构设计，也可以被作为架构原型的测试起点。

逻辑视图（Logical view）

描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由 UML 的组件图和类图来表示。

物理视图（Physical view）

描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。包括系统组件的物理拓扑、各组件之间的物理连接，也被称为 “部署视图”，一般会通过 UML 中的部署图来表示；

处理流程视图（Process view）

用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程，通常通过 UML 中的时序图、活动图和通讯图来表示；

开发视图（Development view）

描述系统的模块划分和组成，以及细化到内部包的组成设计，也被称为 “实现视图”，服务于开发人员，反映系统开发实施过程。一般会通过 UML 中的组件图和包图来表示；

C4 模型画图法

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。

1. 语境图（System Context Diagram）：用于描述要构建的系统是什么，它的用户是谁，谁会用它，它要如何融入已有的 IT 环境。例如：这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。
   

2. 容器图（Container Diagram）：容器图是把语境图里待建设的系统做了一个展开，用于展现软件系统的整体形态。例如：除了用户和外围系统，要建设的系统包括一个基于 Java Spring MVC 的 Web 应用提供系统的功能入口，基于 Xamarin 架构的手机 APP 提供手机端的功能入口，一个基于 Java 的 API 应用提供服务，一个 MySQL 数据库用于存储，各个应用之间的交互都在箭头线上写明了。
   

3. 组件图（Component Diagram）：组件图是把某个容器进行展开，描述其内部的模块。用于描述系统由哪些组件/服务组成，厘清组件之间的关系和依赖，为软件开发如何分解交付提供了框架。
   

4. 类图（Code/Class Diagram）。