系统从收集、整理需求到实现

业务分析与架构设计

业务分析，主要处理的是业务领域建模。业务上实现
技术与架构，主要针对的技术实现

理清业务需求

理清业务需求是所有分析与设计的前提：

• 确定系统的利益相关者（Stakeholder）及他们的关注点。
• 确定系统的业务需求，即「谁」使用该系统「做什么」。
• 确定系统的功能范围，即该系统「包含什么」，不包含「什么」。

如门诊预约系统：

建立实体模型

• 确定系统包含的实体以及之间的关联

分析业务场景

• 分析用于确定具体业务场景，交互过程
• 确定业务规则，梳理业务流程
• 转换逻辑

架构与技术设计

确定整体架构

• 确定系统在整个上下文中的位置，与其他系统的关联
• 确定系统自身以及各个外部系统的职责

可以将这步看作一个黑盒

设计功能模块

• 确定系统的模块划分
• 确定每个模块的职责以及模块间的关联

明确架构关注点

• 理清架构设计需要考虑的关注点
• 确定系统的架构上的取舍
• 要从以下内容考虑

安全性
性能
稳定性
扩展性
其他 易用性 合规性

设计数据库模型

• 有了完善的实体模型，设计数据库模型就很快了
• 需要注意的是，数据库模型是实体模型在关系数据库的实现，但不一定严格映射
• 三大范式

冗余
一致性
同步
分表分库

设计接口

然后设计接口，确定API接口细节。设计阶段，可以通过Markdown文档、Swagger和代码一起维护

• 接口的设计应该以系统提供的领域资源或服务为基础，同时考虑调用方的需求
• 接口的设计也需要从调用方的角度考虑如何进行调用。有必要可以话流程图
• 接口的文档一定要清楚的说明调用的方法、前置条件、参数作用、不同条件的处理、返回接口等

场景实现

有了前面的步骤。系统的实现就很简单明了了，还是有进一步的考虑细节，以避免风险
复杂业务场景的详细设计，或复杂算法的实现描述
非业务的一些场景

其他考虑

框架确定，可以解决很多基础的非业务需求。还要考虑一下方面

• 数据迁移、同步和回滚方案
• 系统部署和发布
• 系统的监控和告警
• 并发和数据量
• 缓存设计
• 技术选型