设计模式之美学习笔记23~24: 业务系统如何做需求分析、系统设计、业务开发
2019-12-27
今天继续打卡学习极客时间上的专栏“设计模式之美”， 本篇是专栏第23, 24节的学习笔记。
笔记 #
这两节分上、下两节主要介绍了对于"业务系统"如何做需求分析、系统设计、代码实现，并且遵循前面已经学过的设计原则。 原文中以一个"积分兑换系统"为实战案例进行介绍。
需求分析 #
我们一般可以经过分析或询问得出一些粗糙、笼统的的功能需求。例如积分系统的两个主要功能是赚取积分和消费积分，赚取积分有不同的渠道、消费积分也有不同的渠道， 不同渠道下有不同的积分赚取和消费的业务规则。
接下来，需要对这些笼统的功能需求的业务进行细节上的细化，可以使用产品的线框图、用户用例(User Case)或用户故事(User Story)来细化业务流程，进行细节的挖掘。
用户用例比较侧重情景化，描述一个用户在一个特定的场景里的一个完整的业务操作流程，所以可以挖掘出更多的细节。
系统设计 #
面向对象设计聚焦在代码层面(主要是类)，系统设计聚焦在架构层面(主要针对模块)。 很多设计原则和设计思想也都可以应用到架构设计中。接下来我们借鉴面向对象设计的步骤，来做系统设计.
系统设计的过程:
- 合理的将功能划分到不同的模块
- 对比面向对象设计中将不同代码放到合适的类中
- 合理的划分模块可以做到模块层面的高内聚、低耦合，使架构整洁清晰
- 如何判断模块划分是否合理，通过划分的模块分析其是否具有高内聚、低耦合特性。例如一个功能的修改或添加，经常需要跨团队、跨项目、跨系统完成，则说明模块划分的不合理，职责不够清晰，耦合过于严重
- 设计模块与模块之间的交互关系
- 对比面向对象设计中的
- 比较常见的交互方式有: 同步调用和基于消息的异步调用，前者简单直接、后者解耦效果好
- 设计模块的接口、业务模型、数据库
业务开发 #
在业务开发前需要做接口设计、业务模型设计和数据库设计。
对于业务模型设计有贫血和充血两种模式，此时要根据问题域的复杂度和具体的场景做出选择。