当前位置:   article > 正文

后端方案设计文档结构模板可参考

后端方案设计文档结构模板可参考

1 方案设计文档整体结构

一,现状:把项目的基本情况和背景都说清楚,让大家达成一个共识,才能进行后面的方案评审和讨论
    1、业务背景:业务(项目)的基本介绍
    2、技术背景:现有技术积淀、架构描述、系统的整体容量
    
二,需求:技术方案一切都是围绕需求来设计,需求清楚之后才能比较好的去评审你的方案
    1、业务需求:业务具体要做的事情
    2、业务痛点
    3、性能需求
    
三,方案描述:把相关可能的方案都描述清楚【可选】
    1、方案1
        概述
        详细说明
        性能目标
        性能评估
        方案优缺点
    2、方案2
    3、方案对比
    
四,线上方案:倾向的方案更为细致的描述
    1、架构图:指出关键设计点和设计折衷
    2、流程图:分业务场景把重要的业务场景的流程图
    3、模块划分:针对这个业务流程的各个环节来划分模块
    4、时序图:
    5、存储设计
    	表结构设计
    	数据库E-R关系
    6、接口定义:列举出接口的结构,参数,返回值等
    5、异常边界【重要】
        模块
        流程
        可能出现的异常情况
        处理方式
    6、统计、监控
    7、灰度、回滚策略
    8、容灾方案
    
五,部署拓扑:线上部署拓扑如何,上下游是如何

六,风险评估
	潜在风险
	
七,阶段规划【架构演进规划】
    1、第一阶段
    2、第二阶段
    3、第三阶段
    
八,工作量评估
	每个模块、每个接口的设计分别需要多长时间,一定要同时包括开发时间、联调时间、测试时间
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49

2 方案详细设计

概要设计到详细设计,从用户需求——>产品文档梳理——>功能设计——>代码开发

这是一种自上而下的设计,需要从用户视角去看系统,有什么缺失,如果有所缺失,应该主动跟进,push缺失部分的完善,而不是相互甩锅,这部分应该是谁谁谁做,不是我们做。实现合作方之间的相互push,一起把产品做好。

2.1 概要设计

包括:

  • 业务架构:从业务用户角度进行考虑,由哪些功能模块组成,https://zhuanlan.zhihu.com/p/342136194

业务架构图一(三步画出产品业务架构图) - 知乎

  • 应用架构:IT系统功能和技术实现,从应用部署服务进行考虑,从开发的角度来考虑功能模块与服务之间的关系,UI层、网关接入层、应用层、基础设施层(微服务之间的关系)

在这里插入图片描述

  • 部署架构:服务之间如何进行部署,用户、网关、网络、防火墙、存储,从用户到存储的全部过程
  • 系统迁移:上线方案,旧有系统如何进行无缝迁移

2.2 详细设计方案

实际上针对的就是业务架构进行下钻,进行更详细的设计,每一层级都基于上一层级所输出的内容,采用的是“结构化思维”

2.2.1 需求分析

这里的需求并非产品经理识别用户需求里面的用户需求,而是针对已有的产品文档输出开发的需求

对于这个服务系统,用户有哪些功能需求,分析之后输出用例图

根据所有用户的用例图,可以从中抽象出功能模块
在这里插入图片描述

2.2.2 业务流程设计

根据需求分析得出的用例图,找到用例图中的核心功能,输出序列图(时序图),有时候业务的流程会比较复杂,涉及到多种角色,这时就可以使用时序图来梳理这个业务逻辑。这样会使业务看起来非常清晰。

实际上越是复杂的功能越是需求进行绘制序列图,通过序列图来理清几个服务之间的交互关系,而这其中的【服务】就对应这应用框架中的【应用】

时序图

  • 每个步骤,增加文字解释+接口设计,文字解释给评审的相关人员看,接口设计给自己开发时使用,实际上也有了接口设计。
  • 每一步的流程交互,在重要的地方可以尽量详细,也就是详略得当,对着就可以进行开发。

绘制参考文章:

程序员必备画图技能之——时序图- 程序员自由之路- 博客园

在线绘图工具,ER模型设计-登录时序图.xml,uml序列图,uml时序图,visio时序图,visio序列图,序列图怎么画,时序图怎么画,系统时序图-

2.2.3 抽象类:实体对象建模

根据核心功能的时序图,分析时序图中涉及有哪些关键的类,这些关键类,又有哪些关键属性,实际上是为了梳理出类与类之间的关系,对应了写代码的思路

有了关键类,则可以为后续的存储设计,数据库表设计,进行参考

英文书写,类名最好直接对应与最后的开发类名

参考文档:http://www.objie.com/article/613ab8af0763c30011fa8daf

软件开发设计文档之「类图」

2.2.4 接口设计

业务流程设计输出的时序图服务与接口设计

2.2.5 存储设计

实体对象建模输出的UML类图服务于存储设计

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/weixin_40725706/article/detail/520803
推荐阅读
相关标签
  

闽ICP备14008679号