第四步：對象設計——從分析模型到技術實現藍圖
在體系架構規範指導下，對象設計將分析結果轉化為可擴展、適應特定技術棧的詳細設計。關鍵差異：
- 分析階段：領域對象模型與技術細節無關
- 設計階段：緊密結合平台、語言、廠商選型（如 J2EE、WebLogic、Oracle）
原則：盡量不修改業務對象，除非為維護其核心屬性行為必須調整。
詳細設計輸出標準
設計說明書應包含所有類的完整規範：
- 必要的實現屬性
- 詳細接口定義
- 偽代碼或操作純文本描述
詳細程度標準：結合模型圖即可獲得所有編程信息。自動化工具可從 UML 圖生成代碼框架。
EJB 設計特殊說明
圖 6：EJB 核心對象關係圖（含 Stub/Skeleton 仅为說明）
- Stub/Skeleton 對設計者/程序員透明，無需在圖中展示，圖中包含僅為說明 EJB 基本點
- 完成詳細對象設計即完成領域對象到關係模型的映射
對象-關係映射（ORM）關鍵性
- 雖面向對象先進，但最流行持久存儲仍為關係數據庫
- 客戶 IT 架構反映現有 RDBMS 投資與廠商選擇
- 將領域對象模型轉換為關係模型/數據庫表至關重要
- 容器管理工具（CMP）不能替代優秀的關係數據庫設計
第五步：實現——良好架構下的清晰編碼
- 擁有優秀架構與詳細設計，實現成為清晰、可預期的任務
- 體系原型階段已設計實現系統一個垂直切片，實現階段少遇意外
常見反模式：過早進入編碼
- 管理者視 UML 繪圖為「浪費時間」
- 開發者在代碼中測試想法，數週/數月後發現方向錯誤
- 架構決策與設計被迫在代碼階段做出，返工成本極高
教訓：先完成設計，再大規模編碼。
第六步：驗證——確保系統符合設計並滿足需求
驗證貫穿開發與部署全周期，核心測試層級：
- 單元測試：驗證最小功能單元（類/方法）正確性
- 集成測試：驗證模塊間接口、數據流、事務邊界
- 用戶驗收測試 (UAT)：驗證業務流程、性能、易用性滿足實際需求
所有測試均為重要主題，不可因趕工期壓縮。
總結：前六步核心價值鏈
| 步驟 | 核心產出 | 關鍵原則 |
|---|
| IV 對象設計 | 詳細類規範、ORM 映射、EJB 組件定義 | 技術落地、不破壞業務模型、Stub/Skeleton 透明化 |
| V 實現 | 可運行代碼、垂直切片驗證 | 設計先行、避免代碼中做架構決策、利用原型減少風險 |
| VI 驗證 | 測試報告、缺陷清單、驗收確認 | 全周期驗證、三層測試體系完整、UAT 為最終質量關 |
扎實完成前六步，為後續部署、運維、演化奠定堅實基礎。
