说明： 

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

正例：

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

说明：

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

正例：

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

说明：

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

说明：

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

说明：

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

反例：

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

说明：

        单一原则是最易理解却又最难实现的一条规则，随着系统的演进，工程师很多时候会忘记类设计的初衷。

说明：

        若一定要使用继承，则必须符合里氏替换原则。此原则要求在父类能够出现的地方子类一定能够出现，比如“把钱叫出来”中，钱的子类美元、欧元、人民币都可以出现。

说明：

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

说明：

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

说明：

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

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

说明：

        时间众多设计模式其实就是一种设计模式，即隔离变化点的模式。

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

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

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

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

说明：

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