设计（参考阿里巴巴Java开发手册）

• UML建模
  • 强制
    • 在需求分析阶段，若是与系统交互的User超过一类而且相关的User Case超过5个，使用用例图来表达更加清晰的结构化需求。
    • 若是某个业务对象的状态超过3个，使用状态图来表达而且明确状态变化的各个触发条件。
      • 说明：状态图的核心是对象状态，首先明确对象有多少种状态，而后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。
      • 正例：淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。好比已下单与已收货这两种状态之间是不可能有直接转换关系的。
    • 若是系统中某个功能的调用链路上的涉及对象超过3个，使用时序图来表达而且明确各调用环节的输入与输出。
      • 说明：时序图反映了一系列对象间的交互与协做关系，清晰立体地反映系统的调用纵深链路。
    • 若是系统中模型类超过5个，而且存在复杂的依赖关系，使用类图来表达而且明确类之间的关系。
      • 说明：类图像建筑领域的施工图，若是搭平房，可能不须要，但若是建造蚂蚁Z空间大楼，确定须要详细的施工图。
    • 若是系统中超过2个对象之间存在协做关系，而且须要表示复杂的处理流程，使用活动图来表示。
      • 说明：活动图是流程图的扩展，增长了可以体现协做关系的对象泳道，支持表示并发等。
• 面向对象设计原则
  • 推荐
    • 类在设计与实现时要符合单一原则。
      • 说明：单一原则最易理解倒是最难实现的一条规则，随着系统演进，不少时候，忘记了类设计的初衷。
    • 谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现。
      • 说明：不得已使用继承的话，必须符合里氏代换原则，此原则说父类可以出现的地方子类必定可以出现，好比，“把钱交出来”，钱的子类美圆、欧元、人民币等均可以出现。
    • 系统设计时，根据依赖倒置原则，尽可能依赖抽象类与接口，有利于扩展与维护。
      • 说明：低层次模块依赖于高层次模块的抽象，方便系统间的解耦。
    • 系统设计时，注意对扩展开放，对修改闭合。
      • 说明：极端状况下，交付线上生产环境的代码都是不可修改的，同一业务域内的需求变化，经过模块或类的扩展来实现。
    • 系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，避免出现重复代码或重复配置的状况。
      • 说明：随着代码的重复次数不断增长，维护成本指数级上升。
• 其余
  • 强制
    • 存储方案和底层数据结构的设计得到评审一致经过，并沉淀成为文档。
      • 说明：有缺陷的底层数据结构容易致使系统风险上升，可扩展性降低，重构成本也会因历史数据迁移和系统平滑过渡而陡然增长，因此，存储方案和数据结构须要认真地进行设计和评审，生产环境提交执行后，须要进行double check。
      • 正例：评审内容包括存储介质选型、表结构设计可否知足技术方案、存取性能和存储空间可否知足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等；数据结构变动（如在原有表中新增字段）也须要进行评审经过后上线。
  • 推荐
    • 需求分析与系统设计在考虑主干功能的同时，须要充分评估异常流程与业务边界。
      • 反例：用户在淘宝付款过程当中，银行扣款成功，发送给用户扣款成功短信，可是支付宝入款时因为断网演练产生异常，淘宝订单页面依然显示未付款，致使用户投诉。
    • 避免以下误解：敏捷开发 = 讲故事 + 编码 + 发布。
      • 说明：敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摒弃传统的审批流程，但核心关键点上的必要设计和文档沉淀是须要的。
      • 反例：某团队为了业务快速发展，敏捷成了产品经理催进度的借口，系统中均是勉强能运行但像面条同样的代码，可维护性和可扩展性极差，一年以后，不得不进行大规模重构，得不偿失。
  • 参考
    • 系统设计主要目的是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。
      • 说明：避免为了设计而设计，系统设计文档有助于后期的系统维护和重构，因此设计结果须要进行分类归档保存。
    • 设计的本质就是识别和表达系统难点，找到系统的变化点，并隔离变化点。
      • 说明：世间众多设计模式目的是相同的，即隔离系统变化点。
    • 系统架构设计的目的：
      • 肯定系统边界。肯定系统在技术层面上的作与不作。
      • 肯定系统内模块之间的关系。肯定模块之间的依赖关系及模块的宏观输入与输出。
      • 肯定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化。
      • 肯定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。
    • 在作无障碍产品设计时，须要考虑到：
      • 全部可交互的控件元素必须能被tab键聚焦，而且焦点顺序需符合天然操做逻辑。
      • 用于登录校验和请求拦截的验证码均需提供图形验证之外的其它方式。
      • 自定义的控件类型需明确交互方式。