業務系統設計規范檢查清單 本清單提供從需求到落地的全流程設計規范，適用于中小規模業務系統，涵蓋需求梳理、數據表設計、代碼分層、擴展規劃等階段。 需求梳理：確保需求真實、清晰、可量化，明確系統邊界，區分必要需求與優化需求，完成多方評審。 數據表設計：遵循數據庫范式，規范字段命名與類型，合理設計索引與表關系，預留擴展字段。 代碼分層：采用經典分層架構（如Controller-Service-DAO），職責單一，避免循環依賴，統一編碼規范。 擴展規劃：模塊化設計，預留分庫分表、讀寫分離、緩存優化等能力，支持API

核心目標：確保業務設計從需求到落地全鏈路規范，減少后期重構成本，保障系統可維護性與可擴展性。本清單適用于中小規模業務系統設計，復雜場景可結合領域驅動設計（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攻擊，權限控制細化到接口/數據級）