1、【强制】存储方案及底层数据结构的设计必须经过集体评审，并形成书面文档留存。
说明：有缺陷的数据结构设计易引发系统风险、降低扩展能力，且后期重构会因数据迁移和系统平滑升级而成本剧增。因此，存储方案与数据结构需经过充分设计与评审，上线前需进行二次复核。
正例：评审应涵盖存储介质选择、表结构能否支撑技术方案、存取性能与存储空间是否满足业务增长、表与字段间的逻辑关系、字段命名与类型、索引设计等；即使只是新增字段，也需通过评审后方可上线。

2、【强制】在需求分析阶段，若系统涉及的用户角色超过一类且相关用例超过 5 个，建议采用用例图来清晰表达结构化需求。
3、【强制】若某一业务对象的状态数量超过 3 个，应使用状态图进行表达，并明确触发状态转移的条件。
说明：状态图的核心在于梳理对象状态种类，厘清状态间是否可直接转换，并定义触发转换的具体条件。
正例：以淘宝订单为例，其状态包括“已下单”“待付款”“已付款”“待发货”“已发货”“已收货”等。例如，“已下单”与“已收货”之间不存在直接状态转换。

4、【强制】若系统中某功能调用链路涉及对象超过 3 个，使用时序图来表达调用关系，并明确各环节的输入输出。
说明：时序图能清晰展示对象间的协作关系，直观呈现系统调用的纵深路径。

5、【强制】若系统中模型类数量超过 5 个且存在复杂依赖，应使用类图进行表达，明确类之间的关联。
说明：类图像建筑领域的施工蓝图，建造简单结构或许不需要，但构建复杂系统时必不可少。

6、【强制】若系统中超过 2 个对象间存在协作且流程复杂，建议使用活动图进行表达。
说明：活动图在流程图基础上增加了对象泳道，可体现协作关系并支持并发流程的表示。

7、【推荐】进行需求分析与系统设计时，除主干流程外，应充分评估异常场景与业务边界。
反例：用户支付时银行扣款成功并发送短信，但因支付宝入账异常导致订单状态未更新，引发用户投诉。

8、【推荐】类的设计与实现应遵循单一职责原则。
说明：该原则最易理解却最难贯彻，系统演进中常会逐渐偏离设计初衷。

9、【推荐】尽量避免使用继承进行扩展，优先考虑聚合或组合方式。
说明：如必须使用继承，需符合里氏替换原则，即子类应能完全替代父类出现。

10、【推荐】遵循依赖倒置原则，设计中应依赖抽象类或接口，以提升扩展性与维护性。
说明：低层模块依赖高层模块的抽象，有助于系统解耦。

11、【推荐】设计时应遵循开放封闭原则，即对扩展开放，对修改封闭。
说明：理想情况下，已交付的代码应不可修改，业务变化通过扩展新模块或类来实现。

12、【推荐】系统设计阶段应将共性业务或公共行为抽取为独立模块、配置、类或方法，避免重复。
说明：重复代码将导致维护成本呈指数级增长。

13、【推荐】避免误解：敏捷开发不等于省略设计。
说明：敏捷开发强调快速交付可用迭代版本，简化冗余流程，但关键环节的必要设计与文档沉淀仍不可或缺。
反例：某团队为追求速度，忽视设计，导致代码难以维护，一年后不得不大规模重构。

14、【参考】系统设计的主要目的是厘清需求、梳理逻辑、便于维护，其次才是指导编码。
说明：应避免过度设计，设计文档需分类归档以支持后续维护。

15、【参考】设计的本质在于识别系统难点与变化点，并将其隔离。
说明：众多设计模式的共同目标即是隔离系统变化。

16、【参考】系统架构设计的目标包括：
界定系统技术边界；

明确模块间依赖关系及宏观输入输出；

确立后续设计与演进原则；

定义非功能性需求，如安全性、可用性、可扩展性等。