《阿里巴巴Java开发手册1.4.0》阅读总结与心得（四）

Dear 丶 2021-11-09 06:20 192阅读 0赞

## ##

## **（七）设计规约** ##

1. 【强制】 存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。

说明： 有缺陷的底层数据结构容易导致系统风险上升，可扩展性下降，重构成本也会因历史数据迁移和系统平滑过渡而陡然增加，所以，存储方案和数据结构需要认真地进行设计和评审，生产环境提交执行后，需要进行 double check。

正例： 评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等；数据结构变更（如在原有表中新增字段）也需要进行评审通过后上线。

2. 【强制】在需求分析阶段，如果与系统交互的 User 超过一类并且相关的 User Case 超过 5 个，使用用例图来表达更加清晰的结构化需求。

3. 【强制】如果某个业务对象的状态超过 3 个，使用状态图来表达并且明确状态变化的各个触发条件。

说明： 状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。

正例： 淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两种状态之间是不可能有直接转换关系的。

4. 【强制】如果系统中某个功能的调用链路上的涉及对象超过 3 个，使用时序图来表达并且明确各调用环节的输入与输出。

说明： 时序图反映了一系列对象间的交互与协作关系， 清晰立体地反映系统的调用纵深链路。

5. 【强制】如果系统中模型类超过 5 个，并且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系。

说明： 类图像建筑领域的施工图，如果搭平房，可能不需要，但如果建造蚂蚁 Z 空间大楼，肯定需要详细的施工图。

6. 【强制】如果系统中超过 2 个对象之间存在协作关系，并且需要表示复杂的处理流程，使用活动图来表示。

说明： 活动图是流程图的扩展，增加了能够体现协作关系的对象泳道，支持表示并发等。

7. 【推荐】需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。

反例： 用户在淘宝付款过程中，银行扣款成功，发送给用户扣款成功短信，但是支付宝入款时由于断网演练产生异常，淘宝订单页面依然显示未付款，导致用户投诉。

8. 【推荐】类在设计与实现时要符合单一原则。

说明： 单一原则最易理解却是最难实现的一条规则，随着系统演进，很多时候，忘记了类设计的初衷。

9. 【推荐】谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现。

说明： 不得已使用继承的话，必须符合里氏代换原则，此原则说父类能够出现的地方子类一定能够出现，比如， “把钱交出来” ，钱的子类美元、欧元、人民币等都可以出现。

10.【推荐】系统设计时，根据依赖倒置原则，尽量依赖抽象类与接口，有利于扩展与维护。

说明： 低层次模块依赖于高层次模块的抽象，方便系统间的解耦。

11.【推荐】系统设计时，注意对扩展开放，对修改闭合。

说明： 极端情况下，交付的代码都是不可修改的，同一业务域内的需求变化，通过模块或类的扩展来实现。

12.【推荐】系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等， 避免出现重复代码或重复配置的情况。

说明： 随着代码的重复次数不断增加，维护成本指数级上升。

13.【推荐】避免如下误解： 敏捷开发 = 讲故事 + 编码 + 发布。

说明： 敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摒弃传统的审批流程，但核心关键点上的必要设计和文档沉淀是需要的。

反例： 某团队为了业务快速发展，敏捷成了产品经理催进度的借口， 系统中均是勉强能运行但像面条一样的代码， 可维护性和可扩展性极差，一年之后，不得不进行大规模重构，得不偿失。

14.【参考】系统设计主要目的是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。

说明： 避免为了设计而设计，系统设计文档有助于后期的系统维护，所以设计结果需要进行分类归档保存。

15.【参考】设计的本质就是识别和表达系统难点， 找到系统的变化点，并隔离变化点。

说明： 世间众多设计模式目的是相同的， 即隔离系统变化点。

16.【参考】系统架构设计的目的：

 确定系统边界。确定系统在技术层面上的做与不做。

 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。

 确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化。

 确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。

转载于:https://www.cnblogs.com/D-ZH/p/11024218.html

发表评论取消回复

表情：

评论列表（有 0 条评论，192人围观）

还没有评论，来说两句吧...

相关阅读

相关 Java开发手册：阿里巴巴

文章目录一、前言二、编程规范 2.1命名规范 2.2常量的定义 2.3代码格式 2.4OOP规约

ゞ浴缸里的玫瑰/ 2024年03月31日 14:03/ 0 赞/ 76 阅读

相关【Java】阿里巴巴Java开发手册

文章目录前言一、编程规约 (一) 命名风格 (二) 常量定义 (三) 代码格式 (四) OOP 规

àì夳堔傛蜴生んèń/ 2023年10月13日 23:36/ 0 赞/ 7 阅读

相关阿里巴巴Java开发手册

![94978f1bf8474dc3b2fe30b0fc0ff29f1e45b277.jpeg][] 阿里巴巴Java开发手册，首次公开阿里官方Java代码规范标准。这套Ja

傷城~/ 2022年07月12日 07:46/ 0 赞/ 313 阅读

相关《阿里巴巴Java开发手册》阅读笔记

1.抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。 2.POJO

妖狐艹你老母/ 2022年06月18日 05:25/ 0 赞/ 294 阅读

相关阿里巴巴 Java 开发手册

备注：对于排版看着不舒服的，可以看看PDF版（[下载地址][Link 1]）。![大笑][laugh.gif] 目录前言 ...................

╰+攻爆jí腚メ/ 2022年05月26日 01:42/ 0 赞/ 358 阅读

相关阅读阿里巴巴Java开发手册的持续感悟中。。。。。。

1.尽量少用if......else超过三层的if......else尽量采用卫语句替代，就是 if(condition){ return;

太过爱你忘了你带给我的痛/ 2022年05月19日 01:17/ 0 赞/ 214 阅读

相关阿里巴巴Java开发手册阅读笔记

前言参考：[阿里巴巴Java开发手册V1.3.0][Java_V1.3.0] 总结比较重要的，对面试有用的开发规约一、编程规约 (一)命名风格

ゝ一纸荒年。/ 2022年04月23日 10:12/ 0 赞/ 299 阅读

相关阿里巴巴 Java 开发手册

无规矩不成方圆，无规范不能协作。《阿里巴巴Java开发手册》（以下简称《手册》）是阿里内部Java工程师所遵循的开发规范，涵盖编程规约、异常日志、单元测试、安全规约、MyS

谁借莪１个温暖的怀抱￠/ 2022年01月27日 11:13/ 0 赞/ 437 阅读

相关《阿里巴巴Java开发手册1.4.0》阅读总结与心得（四）

（七）设计规约　　1. 【强制】存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。　　说明：有缺陷的底层数据结构容易导致系统风险上升，可扩展性

Dear 丶/ 2021年11月09日 06:20/ 0 赞/ 193 阅读

相关《阿里巴巴 Java开发手册》读后感

前言 > 只有光头才能变强前一阵子一直在学Redis，结果在黄金段位被虐了，暂时升不了段位了，每天都拿不到首胜(好烦)。趁着学校校运会，合理地给自己放了一个小长假

痛定思痛。/ 2021年09月17日 01:04/ 0 赞/ 478 阅读