人人都是好的软件开发设计师(技术设计金字塔)

父文章

     如何成为一名架构师,架构师成长之路_个人渣记录仅为自己搜索用的博客-CSDN博客_架构师成长之路

相关文章    技术人人都是好的需求评审专家- 如何需求评审,需求评审评什么._个人渣记录仅为自己搜索用的博客-CSDN博客_需求评审技术

相关文章 

     业务系统中最核心的状态设计,异常 case. (系统设计) - fei33423 - 博客园

目录

父文章

模板

技术review五大金刚

需求的概要设计 (本质上是需求设计,交互设计的深究,合理性)

程序的详细设计

        程序的复杂度量

内存中领域类的设计

方法论 - 技术设计金字塔

写流程:

实体设计

状态设计

字段设计

流程设计

数据设计

读流程

附录

排期task设计

 业务场景思考完备性举例: 

 可读/可维护的的代码

 流程复用,策略点的复用.(流程复用本质上隐含了 实体复用, 父类抽象)



模板

  软件开发系统分析模板

技术review五大金刚

 核心技术review 五大金刚 安全-稳定-性能 - 成本 - 体验 

https://www.yuque.com/u16469/safsgdg/cydpnu

需求的概要设计 (本质上是需求设计,交互设计的深究,合理性)

   流程 + 状态图 + 约束 (约束,异常) 

程序的详细设计

   字段 + 流程 + 状态设计 ( 约束,异常,核对 )  

        程序的复杂度量

                如何梳理和重构_含复杂性度量

内存中领域类的设计

   = 当前系统的表 + 下游接口的显性字段 + 透传字段string.

方法论 - 技术设计金字塔

    设计金字塔从设计深度上总结. (方法论就是通过整理-分类- 多维度表格呈现的结果. 通常的维度有 时间/空间/深度/广度.)

   正常,异常 通过 概要设计状态图, 状态机的约束能自然而然的想到. 状态校验和参数校验是必须的, 是兜底, 但不是异常点.

    扩展性 其实是伪命题. 不为扩展设计, 有单测和集成测试覆盖率就不怕.

软件项目需求分析:非功能性六大点_研发项目非功能性特性分析_nnsword的博客-CSDN博客

其他 异常情况罗列详见 需求拆分 概要设计 详细设计(系分)流程总览_软件功能需求拆分_个人渣记录仅为自己搜索用的博客-CSDN博客

  业务技术

正常功能

(1. 设计阶段要补充产品未想到的用例,见附录的排期task设计)

实体/表设计ddd设计

异常

(补充: 面向结构化监控)

业务异常. 本质上应该是正常功能, 可能产品没有想到. 业务是的并发竞争. 例如最下面的排队投屏竞争.

技术异常

下游识别, db识别

扩展性业务功能增加,代码是否够优雅量增加
性能
安全攻击uid校验,同组织验证等.
其他底层安全防控.
成本

本文重点自顶向下

findbug,代码检测,坏味道,代码重构都是自下向上.都是需要掌握的,更具有操作性.

写流程:

实体设计

   静态设计
       1. 这个是核心,外延到架构. 1:many等. 扩展性 . 对many的这种,还需要考虑扩展性,接入效率.(新的接入方,新的渠道)

      2. 各个模块上下游链路的的效率问题
   动态拆:   

   交易系统模块划分,模块拆分,设计,重构实战.状态

   领域驱动设计DDD 代码框架 案例 demo
    支付系统-帐户系统总结

状态设计

   1. 状态的合并,分拆.
   状态设计文章1

   流程引擎状态设计

    最佳实践 状态设计

   最佳实践 根据状态操作,这样能避免吃掉异常

   业务系统中最核心的状态设计,异常 case. (系统设计)

   从接口的前置状态校验 到 状态模式的方法是否能执行 再 有限状态机(FSM)的事件校验 ,状态机

字段设计

   字段设计依赖于信息呈现,而不是行为. 前后台数据分开. 字段查询频率分开. 前台查,后台查,odps查. 分开到不同表中. 甚至有些只log, 异步存储.

流程设计

   1. facade系统 需要实现底层的spi,同时暴露给上游spi. 信息并不是在初始化流程时全部存储,仅需保存相关id. 校验也可以放到各个流程的同步spi上.

   2. 上下生命周期(例如支付,退款)可放置到不同的领域EO中

   3. 并行生命周期

数据设计

   1.业务可追溯(type,两码)

   2.不同业务方数据可标准化.(type不足,场景:账单场景) (spi方式来获取,而不是让业务方发送mq. 数据一致性, 补偿操作由平台系统来管控.)

对于"可值班",举个例子:

    排队投屏, 一旦感知设备不在投屏中,直接投屏. 在投屏中,参与排队. 如果是依赖服务端状态,设备出bug,没有上报,服务端的状态和设备端不一致, 那么问题就来了,用户本来想排队然后就投屏成功了. 

  1.服务端对状态不一致无感知,只能统计监控,无法值班监控,也无法行为级分析.

  哪怕统计粒度出问题,你也无法知道哪个设备出了问题.

读流程

     同样如上,只是字段和存储完全不同了. DQRS

附录

排期task设计

 task需完备 (基于状态设计,本质是用例设计,产品/交互的工作) (同时也是测试case的重要依据)

 依赖于
    1. 角色定义,角色本来就是某种状态下的人员定义 
    2. 角色行为.
    3. case遍历全,依赖于角色设计+状态遍历.

 业务场景思考完备性举例: 

    投屏人,排队人, 抢占者. - 业务场景思考的完备性. 可能需要自己补充

    投屏人:  定义比较宽泛,状态,有一台设备,有一个投屏工具.
    排队人:  当前有一个投屏人.action: 排队. 后续角色变更: 可变成抢占人[直接选择抢占]. 或者 投屏人[之前投屏人正常结束].
     抢占人:  当前有一个投屏人. action:抢占. 后续角色变更: 无
     第三排队人: 当前有个投票人且有个排队人.  action: 抢占或者重试排队. 后续角色变更: 排队人或者抢占人

 可读/可维护的的代码


如何写可维护的代码 - 万物ddd ddd primitive . 封装,对象来实现可维护代码._个人渣记录仅为自己搜索用的博客-CSDN博客_ddd 代码demo

 流程复用,策略点的复用.(流程复用本质上隐含了 实体复用, 父类抽象)

  会导致流程模板的嵌套. 例如某个业务流程有很多, 需要依赖某个业务的一个流程.

  方案一: 引擎type法. 通过某个type处理不同的业务. 也可以通过异步化解耦.

  方案二: 组合法. 另外一个模式是 组合模式. 在入口处先判断业务. 使用不同的业务实体/流程.

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值