代码需要考虑

按层设计                                   业务线

 

        |-------------------------------|---案件----|-零售户-|-零售许可证审批-|-市场检查-|--订单--|-身份证-|-工商营业执照-|-车輌-|-驾驶证-|

   稳   |2、存储层                      |           |   

   定   |                               |           |   

        |1、核心业务层  按管理对象      |           | 

========================================|===========|========================

 

=============================================================================

   不   |4、应用层 按应用 跟页面        |           |  

   稳   |     副2、鉴权层 集成钉钉 经管 |           |  

   定   |3、展示层  =  PC + 移动        |           |    

        |-------------------------------|           |

 

--面向对象的设计方式

--面向数据库设计方式

 

PC和移动端 

    概要设计:高仿原型,说明每个按钮链接做什么用 基本数据类型验证

    详细设计:集成部分,按钮或者链接背后的故事, 按钮要发送请求对应那个或者那些接口(应用层),接口间调用顺序

 

服务层

    概要设计:我需要管理那些对象(或者数据库表)

    详细设计:根据业务流程,业务验证,业务处理

 

应用层

    设计:前后端桥梁,做控制反转

    

-------------------------------------------------------------------------------------------------------------------------------------------------------

Server层

-----------------------------------------------------------------

日志处理 

       feed log(用于程序流转跟踪),

       transaction log (用于重要业务跟踪,记录输入输出)

       event log (用于程序异常跟踪)

-----------------------------------------------------------------

请求及返回

       服务层

              请求头

              请求体

       应用层

              请求头

              请求体

-----------------------------------------------------------------

输入校验

             用户输入校验 (业务异常 转前端处理,框架考虑统一处理)

             第三方系统输入校验(例如经管) (技术异常 记录日志 转开发,框架考虑统一处理)

------------------------------------------------------------------

异常处理

       异常分类

              输入异常 

                     基本数据校验( 框架处理  业务异常 转前端处理)

                     业务数据校验( 业务代码  业务异常 转前端处理 手动抛出)

              代码异常

                     程序考虑不足,修改代码转输入异常 (技术异常 转开发修复)

                     非程序或输入问题(例如:网路,内存 第三方系统未知异常)(技术异常 记录日志 转运维排查)

       抛出

              

       处理

------------------------------------------------------------------

事务

              事务业务 

                     通知型 最大努力方案 如果n次后依然失败,发邮件、短信,用人肉来兜底

                                业务补偿

              交易业务

                     补偿型 TCC方案

类型 名称 数据一致性的实时性 开发成本 上游服务是否依赖下游服务结果

通知型 最大努力               低 低 不依赖

通知型 可靠事件               高 高 不依赖

补偿型 业务补偿               低 低 依赖

补偿型 TCC               高 高 依赖

------------------------------------------------------------------

远程(本地)调用

       阿里 HSF

       spring

------------------------------------------------------------------

代码与文档互转

       swigger

       cxf documentation

------------------------------------------------------------------

特例实现

       基于企业集成

       基于数据总线

------------------------------------------------------------------

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值