核心目标：确保业务设计从需求到落地全链路规范，减少后期重构成本，保障系统可维护性与可扩展性。本清单适用于中小规模业务系统设计，复杂场景可结合领域驱动设计（DDD）进一步细化。
一、需求梳理阶段：对齐目标，明确边界
关键原则：需求需“可量化、无歧义、强关联业务目标”，避免“想当然”式设计。
| 检查维度 | 核心检查点 | 验证方式/标准 |
|---|---|---|
| 需求真实性 | 是否明确需求提出者及核心诉求？ | 有明确的需求来源（如业务方、用户调研），记录需求背景（如“解决线下对账效率低问题”） |
| 是否区分“必要需求”和“锦上添花需求”？ | 通过MoSCoW法则标注：M（必须有）、S（应该有）、C（可以有）、W（暂不需要） | |
| 需求是否与业务目标强关联？ | 可对应到具体业务指标（如“提升订单转化率5%”“减少客服咨询量30%”） | |
| 需求清晰度 | 是否用“用户故事”或“场景描述”明确流程？ | 格式：“作为[角色]，我需要[操作]，以便[达成目标]”，无模糊表述（如避免“优化界面”） |
| 是否明确输入/输出、异常场景？ | 梳理“正常流程+异常流程”（如“下单时库存不足如何处理”“支付超时如何回滚”） | |
| 是否完成需求评审，相关方无异议？ | 有评审记录，业务方、产品、开发、测试签字确认 | |
| 边界界定 | 是否明确本业务与其他系统的交互边界？ | 绘制“系统交互图”，标注接口、数据流向（如“调用支付系统完成收款”） |
| 是否排除“超出业务范围”的需求？ | 明确“不做什么”（如“本系统只负责订单创建，不负责物流跟踪”） |
二、数据表设计阶段：规范结构，兼容变化
关键原则：满足第三范式（减少冗余），同时预留扩展空间，避免频繁改表。
| 检查维度 | 核心检查点 | 验证方式/标准 |
|---|---|---|
| 范式合规性 | 是否满足第一范式（字段不可再分）？ | 无“复合字段”（如“地址”不存“省+市+区”，需拆分为3个独立字段） |
| 是否满足第二范式（消除部分依赖）？ | 非主键字段必须完全依赖主键（如“订单详情表”主键为“详情ID”，而非“订单号+商品ID”） | |
| 是否满足第三范式（消除传递依赖）？ | 非主键字段不依赖其他非主键字段（如“订单表”存“用户ID”，不直接存“用户名”，通过关联用户表获取） | |
| 基础规范 | 是否统一主键设计？ | 优先自增ID（如id bigint auto_increment）或UUID，不使用业务字段（如手机号、订单号）作为主键 |
| 是否包含“基础审计字段”？ | 必含create_time（创建时间）、update_time（更新时间），可选create_user_id、update_user_id | |
| 字段命名是否规范？ | 采用“下划线命名法”（如order_id），避免中文、拼音、特殊字符，字段含义清晰（如不用“name1”代指“收货人姓名”） | |
| 是否合理设置字段类型/长度？ | 避免“大字段滥用”（如用varchar(50)存手机号，不用text；用int存年龄，不用varchar） | |
| 扩展兼容性 | 是否预留扩展字段？ | 高频变化场景加1-2个通用字段（如ext1 varchar(255)）或JSON字段（如extend_info json） |
| 状态字段是否用枚举值？ | 用数字枚举（如order_status tinyint：1=待支付、2=已支付、3=已取消），而非文字（如“待支付”），并备注枚举含义 | |
| 是否合理设计索引？ | 查询频繁字段（如user_id、order_status、create_time）加索引；避免过度索引（单表索引不超过5个） | |
| 关系设计 | 表间关系是否清晰（一对一/一对多/多对多）？ | 通过ER图可视化（如PowerDesigner绘制），多对多场景必须加中间表（如“商品-订单”中间表“order_product”） |
| 是否避免“循环依赖”？ | 如A表存B表ID，B表不存A表ID，通过中间表或关联查询实现双向关联 |
三、代码分层阶段：高内聚低耦合，易维护易调试
关键原则：每层职责单一，依赖关系清晰（上层依赖下层，不反向依赖），符合行业主流架构规范。
| 检查维度 | 核心检查点 | 验证方式/标准 |
|---|---|---|
| 分层架构合规性 | 是否采用经典分层（以Java为例）？ | 实体层（Entity）→ 数据访问层（DAO/Mapper）→ 业务层（Service）→ 表现层（Controller），无跨层调用（如Controller直接调用DAO） |
| 各层职责是否单一？ | Controller：仅接收请求、参数校验、返回结果；Service：仅处理业务逻辑；DAO：仅操作数据库；Entity：仅定义数据结构 | |
| 是否使用“DTO/VO”隔离数据传输？ | 前端交互用VO（视图对象），服务间调用用DTO（数据传输对象），不直接暴露Entity给外部 | |
| 是否避免“业务逻辑冗余”？ | 重复逻辑抽为工具类（Util）或公共Service，不复制粘贴（如“日期格式化”统一封装为DateUtil） | |
| 编码规范 | 命名是否统一规范？ | 类名：帕斯卡命名法（如OrderService）；方法名/变量名：驼峰命名法（如createOrder）；常量：全大写+下划线（如ORDER_STATUS_PAID） |
| 是否处理异常场景？ | 用统一异常处理器（如@RestControllerAdvice），避免try-catch嵌套；自定义业务异常（如OrderNotFoundException），不直接抛RuntimeException | |
| 是否添加必要注释？ | 类注释：说明功能、作者、创建时间；方法注释：说明入参、出参、异常场景；复杂逻辑加行内注释 | |
| 是否遵循“开闭原则”？ | 新增功能通过“接口+实现类”扩展（如PayService接口，实现WechatPayService、AlipayService），不修改原有代码 | |
| 依赖管理 | 是否避免“循环依赖”？ | 通过“依赖注入”（如Spring @Autowired），不手动new对象；若出现循环依赖，用@Lazy或拆分为第三方服务 |
| 是否控制第三方依赖数量？ | 仅引入必要依赖，避免“依赖膨胀”（如用JDK原生工具类，不重复引入第三方工具包） |
四、拓展规划阶段：预留空间，平滑升级
关键原则：提前预判业务增长（如数据量、用户量、功能扩展），设计时预留扩展点，避免“重构式升级”。
| 检查维度 | 核心检查点 | 验证方式/标准 |
|---|---|---|
| 功能拓展 | 是否采用“模块化设计”？ | 按业务域拆分模块（如订单模块、商品模块、支付模块），模块间通过接口通信，可独立部署（如未来拆分微服务） |
| 接口是否预留扩展参数？ | API设计时加“扩展参数”（如extendParams Map<String, Object>），新增功能不修改接口结构 | |
| 是否支持“插件化/配置化”？ | 高频变化的规则（如优惠策略、风控规则）通过配置文件或数据库存储，不硬编码（如“满减规则”存于rule表，动态读取） | |
| 性能拓展 | 是否预留“分库分表”能力？ | 主键设计支持分片（如用雪花算法生成分布式ID，避免自增ID分表冲突）；大表（如订单表）按“用户ID哈希”或“时间范围”规划分表规则 |
| 是否支持“读写分离”？ | 数据访问层支持路由配置（如MyBatis-Plus读写分离插件），主库写、从库读，未来可新增从库扩容 | |
| 是否考虑“缓存优化”？ | 热点数据（如商品详情、用户信息）预留缓存接口（如Redis缓存），避免直接查库；设计缓存失效策略（如TTL过期+主动更新） | |
| 兼容与迁移 | API是否做版本控制？ | 接口路径加版本号（如/api/v1/order），升级时发布v2版本，老版本兼容运行，逐步灰度切换 |
| 是否预留“数据迁移”方案？ | 设计数据表时考虑未来迁移成本（如字段类型兼容、索引可平滑删除）；复杂迁移需编写脚本并测试 |
五、通用检查项（全流程适用）
-
文档完整性：是否输出配套文档？（需求文档、ER图、架构图、接口文档、编码规范文档）
-
评审机制：各阶段是否经过评审？（需求评审、设计评审、代码评审），有评审记录和问题整改跟踪
-
测试覆盖：是否考虑测试场景？（单元测试覆盖核心业务逻辑，集成测试覆盖系统交互，压力测试验证性能）
-
安全合规：是否符合安全要求？（敏感数据加密存储，接口防SQL注入、防XSS攻击，权限控制细化到接口/数据级）