标签:重用 -- out 分离 需求 接口 com var otto
解
决
方
案
XXXX科技有限公司
XXXX年XX月
目录
本文档的详细描述了修车养车网支付系统项目的每个功能的设计方案。例如功能的需求来源,与各功能模块之间的关系,功能操作流程示例,序列图,程序设计,外部接口,数据库设计等。开发人员可通过阅读该文档快速的了解每一个功能的业务逻辑,便于日后在对系统进行修改时确认修改内容是否正确。
同时本文档也是与终端用户(在本项目中大多数情况是技术支持人员)进行系统功能确认,业务流程确定的唯一文档。
由于公司多个系统都用到了支付模块,而且功能等方面都一致。
把支付模块单独整理出来,然而实现统一管理、维护方便、并且方便以后新系统的开发。
保证支付的安全性,一致性,不影响原系统的支付,在原有系统上以最小的改动方面来实现这个支付的分离。
Ø 原各系统的支付
Ø 问题分析
从上图可以看出我们这个养车修车网有好修养、好淘气、等多个项目。然而他们都需要用到支付宝、微信、银联这三个第三方支付。那么既然都是同一个平台的系统,每个系统支付都重新写,或者以后又有新项目支付又要写支付。
得出以下结论:
1. 代码重用性不高
2. 维护不方便
Ø 解决问题
为了解决上面存在的问题,将原来各系统的支付独立分离出来整合成一个支付系统。现在就是由各个系统去和这个独立出来的支付系统交互,然后在由支付系统再去调用第三方支付(微信、银联、支付宝)进行交互。这样即使有新的系统需要用到支付也不要重新写支付的功能,然后也也方便以后的管理维护。
各个系统调用支付系统,然后我们在根据出传入的支付途径的调用对应的第三方支付进行支付(WEB)或者返回相应的属性(APP),并且返回成功或失败。
各个系统调用支付系统,然后我们在根据出传入的支付途径的调用对应的第三方支付进行退款,并且返回成功或失败。
第三方通知我们的支付系统的回调地址,然后我们验证签名和参数解析,如果支付成功就修改付款单支付状态为已支付,然后根据在通知付款单的系统ID将结果通知对应的系统,如果通知失败就隔1秒在失败就隔2秒依次加时间请求,超过20次就添加到系统日志里面。
第三方通知我们的支付系统的回调地址,然后我们验证签名和参数解析,如果支付成功就修改付款单支付状态为已支付,然后根据在通知付款单的系统ID将结果通知对应的系统,如果通知失败就隔1秒在失败就隔2秒依次加时间请求,超过20次就添加到系统日志里面。
[这里描述系统的性能需求。]
[这里描述系统的安全方面的需求。]
[这里描述和系统相关的用户,包括客户,最终用户细分,他们在系统中的职责,以及他们如何使用系统。简单的说,就是本系统的所有干系人及职责描述,相当于用例分析中的角色。]
[这里描述系统的所有功能需求,可以使用用例图,如果功能需求比较多,可以采用用例包。最好在开始时,给出系统用例图。]
[这里描述对架构设计有指导性的关键需求,会影响到后面的架构设计。]
[这里描述系统的总体设计目标。]
[这里描述系统的总体设计原则。]
[这里以逻辑结构图(一般分层组织)的方式,描述我们提供的整个软件生态系统,一般不涉及具体的技术。]
[这里用网络拓扑图的形式描述网络方面的设计。]
[这里描述硬件方面的设计,一般包括:数据库服务器、备份服务器、Web服务器、应用服务器、存储设备、防火墙等。]
[这里描述硬件服务器的选型,依据内容多少,目录可自行添加。]
[这里描述网络设备的选型,依据内容多少,目录可自行添加。]
[这里描述存储设备的选型,依据内容多少,目录可自行添加。]
[这里列出所有数据库,应用服务器,web服务器,操作系统等软件平台的选型,可以包含介绍和选择理由。]
[在有些大型系统中,需要做开创性的规范方面的设计,用来指导后面系统的开发。一般就是数据方面的规范。这里可以分两个方面进行描述,一个是规范采用的技术,一般是xml;另一个就是规范初步设计。]
[描述整个技术架构的设计思路,一般是介绍架构设计的历史,引导出本系统实际的符合先进行的架构思路。]
[简要描述设计原则,一般都是都是固定的,可参考指南。]
[列出所有架构决策的要点,并逐点解释其与架构需求的对应。]
[给出方案所选平台的技术架构,一般是采用厂商平台的技术架构,可以从厂商网站或ppt中拷贝。]
[在平台架构的基础上,给出具体针对本项目的技术架构。 ]
[对上面的技术架构进行说明]
[按子系统或模块进行组织,可以使用树形图表示。]
[视客户具体要求,可独立章节,写方案时应考虑招标方的具体安全需求,并给出具体的建议措施。]
标签:重用 -- out 分离 需求 接口 com var otto
原文地址:http://www.cnblogs.com/hezhao/p/7392039.html