赞
踩
一,现状:把项目的基本情况和背景都说清楚,让大家达成一个共识,才能进行后面的方案评审和讨论 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、第三阶段 八,工作量评估 每个模块、每个接口的设计分别需要多长时间,一定要同时包括开发时间、联调时间、测试时间
从概要设计到详细设计,从用户需求——>产品文档梳理——>功能设计——>代码开发
这是一种自上而下的设计,需要从用户视角去看系统,有什么缺失,如果有所缺失,应该主动跟进,push缺失部分的完善,而不是相互甩锅,这部分应该是谁谁谁做,不是我们做。实现合作方之间的相互push,一起把产品做好。
包括:
实际上针对的就是业务架构进行下钻,进行更详细的设计,每一层级都基于上一层级所输出的内容,采用的是“结构化思维”
这里的需求并非产品经理识别用户需求里面的用户需求,而是针对已有的产品文档输出开发的需求
对于这个服务系统,用户有哪些功能需求,分析之后输出用例图
根据所有用户的用例图,可以从中抽象出功能模块
根据需求分析得出的用例图,找到用例图中的核心功能,输出序列图(时序图),有时候业务的流程会比较复杂,涉及到多种角色,这时就可以使用时序图来梳理这个业务逻辑。这样会使业务看起来非常清晰。
实际上越是复杂的功能越是需求进行绘制序列图,通过序列图来理清几个服务之间的交互关系,而这其中的【服务】就对应这应用框架中的【应用】
时序图
绘制参考文章:
根据核心功能的时序图,分析时序图中涉及有哪些关键的类,这些关键类,又有哪些关键属性,实际上是为了梳理出类与类之间的关系,对应了写代码的思路
有了关键类,则可以为后续的存储设计,数据库表设计,进行参考
英文书写,类名最好直接对应与最后的开发类名
参考文档:http://www.objie.com/article/613ab8af0763c30011fa8daf
业务流程设计输出的时序图服务与接口设计
实体对象建模输出的UML类图服务于存储设计
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。