《阿里巴巴开发手册》读书笔记-设计规约
其他
2020-03-17 12:40:15
阅读次数: 0
设计规约
- 存储方案和底层数据结构的设计获得评审一致通过,并沉淀成为文档
- 有缺陷的底层数据结构容易导致系统风险上升,可扩展性下降
- 重构的成本也会因历史数据的迁移和系统平滑过渡而陡然增加
- 所以,存储方案和数据结构需要认真地进行设计和评审,生产环境提交执行后,需要进行double check
- 评审内容包括:
- 存储介质选型
- 表结构设计能否满足技术方案
- 存取性能和存储空间能否满足业务发展
- 表或字段之间的辩证关系
- 字段名称
- 字段类型
- 索引等
- 数据结构变更,比如在原有表中新增字段也需要进行评审通过后上线
- 在需求分析阶段,如果与系统交互的User超过一类并且相关的User Case超过5个,使用用例图来表达更加清晰的结构化需求
- 如果某个业务对象状态超过3个,使用状态图来表达并且明确状态变化的各个触发条件
- 状态图的核心是对象状态:
- 首先明确对象有多少种状态
- 然后明确两两状态之间是否存在直接转换关系
- 再明确触发状态转换的条件是什么
- 如果系统中某个功能的调用链路上的涉及对象超过3个,使用时序图来表达并且明确各调用环节的输入和输出
- 时序图反映了一系列对象间的交互与协作关系,清晰立体地反映系统的调用纵深链路
- 如果系统中的模型类超过5个,并且存在复杂的依赖关系,使用类图来表达并且明确类之间的关系
- 类图像建筑领域的施工图,如果搭平房,可能不需要,但如果建造空间大楼,肯定需要详细的施工图
- 如果系统中超过2个对象之间存在协作关系,并且需要表示复杂的处理流程,使用活动图来表示
- 活动图是流程图的扩展,增加了能够体现协作关系的对象泳道,支持表示并发等
- 需求分析与系统设计在考虑主干功能的同时,需要充分评估异常流程和业务边界
- 用户在淘宝付款过程中,银行扣款成功,发送给用户扣款成功信息,但是支付宝入款时由于断网演练产生异常,淘宝订单页面依然显示未付款
- 类的设计与实现要符合单一原则
- 单一原则是最容易理解但是最难实现的一条原则
- 随着系统的演进,忘了设计类的初衷
- 谨慎使用继承的方式来进行扩展,优先使用聚合或者组合的方式来实现
- 使用继承的话,必须符合里氏代换原则
- 里氏代换原则表示父类能够出现的地方,子类一定能够出现
- 系统设计时,根据依赖倒置原则尽量依赖抽象类与接口,有利于扩展和维护
- 系统设计时,注意对扩展开放,对修改闭合
- 在极端的情况下,交付的代码都是不可修改的,同一业务内的需求变化,通过模块或类的扩展来实现
- 系统设计阶段,共性业务或公共行为抽取出来公共模块,公共配置,公共类,公共方法等,避免出现重复代码或者重复配置的情况
- 敏捷开发是快速交付迭代可用的系统,省略多余的设计方案,摒弃传统的审批流程,但核心关键点上的必要设计和文档沉淀是需要的
- 系统设计的主要目的是明确需求,理顺逻辑,后期维护,次要目的是用于指导编码
- 避免为了设计而设计,系统设计文档有助于后期的系统维护,所以设计结果需要进行分类归档保存
- 设计的本质就是识别和表达系统难点,找到系统的变化点,并隔离变化点
- 系统架构设计的目的:
- 确定系统边界. 确定在系统层面上的做与不做
- 确定系统内模块之间的关系. 确定模块之间的依赖关系及模块的宏观输入与输出
- 确定指导后续设计与演化的原则. 使后续的子系统或模块设计在规定的框架内继续演化
- 确定非功能性需求. 非功能性需求指安全性,可用性,可扩展性等
发布了127 篇原创文章 ·
获赞 109 ·
访问量 2万+
转载自blog.csdn.net/JewaveOxford/article/details/104717518
