分析、设计和架构的区别

系分 = 业务分析 + 系统设计

系分其实就是 Analysis + Design

业务分析才是最重要的大头

要理解：

  1. 架构约束
  2. 项目约束

要有：

  1. 权衡
  2. 选择
    的过程

理解业务，要理解业务背后的东西，产出的是模型。
一步一步走，推演出来解决方案，要有方法论。

系统设计是很明确的工作了

应用设计 + 数据设计 + 技术设计 = 系统方案

要考虑的额外问题：

  1. 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。
  2. 项目约束

常见方法论

用例驱动设计
SOAD 面向服务的分析和设计
OOAD 面向对象分析和设计
DDD 领域驱动设计

DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。
这几种方法论可以混合使用。

需求分析与业务建模

把 prd 从薄读到厚，把文档中缺失的部分补全。

系分做 PRD 评审的时候，影响比较大的点一定要尽早确认。一些对系统变化可控，可预测的变化，可以暂时放过，后续在补充。

面向服务的业务建模

分析主业务服务，设计业务功能域，设计业务功能域边界。这个过程可能不断地螺旋式地重构。

如果用泳道来画流程图，则每一个泳道都可以得到一个服务域。

一组业务功能域要有明确的职责分配。

对业务流程的分析也要很仔细。

要随时停下来思考：

  1. 看看是不是交互过于复杂、频繁。要停下来重新设计内聚和耦合关系。
  2. 要思考通信协议的影响。
  3. 要思考对其他系统的影响。
  4. 要思考异常流程的影响。
  5. 考虑要不要使用现有的技术平台。
  6. 要符合现有应用的架构，技术的标准。

领域建模

用科学方法找到系统模式。

寻找到名词和动词，模型客观而抽象地描述了事实，而且带有结构、状态和行为。

OOD 到 OOP 产生的类最少。

SOAD 到 SOAP 产生的类比较多。

DDD 产生的类比较多。

有些地方流程图表达不出来，需要使用状态图表达。

非功能设计与验证

可维护性

回答一个问题，谁来维护，维护什么？

要写好注释和文档，把设计的缺陷和原因讲清楚。

分层

分层可以让依赖清晰

突破模式

  1. 反响依赖
  2. 循环依赖

一定要可控，而且有收益。