第3章 抽象建模
某种意义上，软件的本质就是抽象，建模则是系统地实施抽象的过程。
1. 抽象思维
(1) 软件世界的抽象
- 命名抽象：一个好名字需要把要义浓缩为一到两个词
- 原则抽象：SOLID(单一功能、开闭原则、里氏替换、接口隔离、依赖反转)
(2) 提升抽象思维的方法
- 自顶向下思考(拆解切分)+自底向上思考(归纳演绎)
- 水平思考(全局视角/发散思维)和垂直思考(深挖关键)
2. 建模方法
(1) 问题空间和解决方案空间
- 问题空间：系统要解决的领域问题，是一个特定范围边界内的业务需求的总和。
- 解决方案空间：通过具体的软件技术手段来进行系统设计和实现。
(2) 领域模型：针对某个特定问题的所有相关方面的抽象模型
- 与DDD领域模型的区别：DDD中的领域模型与代码实现紧密相关，属于软件开发中的解决方案空间，而非问题空间。
- 本书的领域模型属于问题空间，是为了准确定义需求解决问题而构建的抽象模型，它与软件实现没有直接关系。
(3) 典型的建模方法
- 用例建模法：整理用例、分析用例、建立模型、梳理关系、验证模型
- 事件建模法：识别事件、识别要素、识别实体、构建模型、验证模型
(4) 建模应遵循的3个原则
- 前面介绍的几种建模法，在实践中大可不必完全遵循，重在借鉴其核心思想，结合实际业务场景灵活应用。
3. 用例建模法知识储备
(1) 用例
- 用例是一种描述需求的方法："角色"通过一系列"步骤"实现"场景"
- 用例的两种表示方式：
-
- (1) 摘要形式：以一段简洁的概要文本表示用例，通常用于描述主成功场景。
- (2) 详述形式：详细编写用例的所有步骤和各种变化，同时具有补充部分，如前置条件、限制与注释等。一般用于编写少量具有高价值和重要架构意义的用例。
- 用例的编写原则：编写用例应从参与者的角度，分析和考察待开发系统的行为，并通过参与者与系统之间的交互关系描述系统对外提供的功能特性。
(2) 挖掘用例的5个步骤
- 确定系统边界：确定待开发的系统和外部环境之间的界限。
- 识别参与者：参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。
- 识别用例：参与者是如何使用系统的。
- 识别用例之间的关系
- 编写用例描述：通过文档或图形来对用例进行较为清晰的描述，描述应避免使用技术用语，而应采用便于理解的业务用语。
(6) 绘制用例图的6个要素：参与者、参与者间的关系、系统边界、用例、参与者与用例的关系、用例之间的关系
4. 用例建模法的4个实施步骤
基于用例结合建模方法论抽象出领域模型，包含以下4个步骤：
(1) 提取模型：分析用例，找出名词 (实体和属性)
(2) 补充属性：通过详述用例对实体属性进行补充
(3) 关系分析：实体间的关系通常以动词和形容词来体现，实体间的关系包括1对1、1对多、多对1、多对多等
(4) 模型验证：反推用例法、留出验证法、流程验证法 (梳理核心业务场景的流程图，并将模型与流程图对照，分析模型是否与流程冲突)
