IV、對象設計 在體系規范的指導下，設計可在技術上擴展和適應分析的結果。分析階段時，域對象模型化應該和技術的細節無關，而對象設計時則是和技術因素密切相關的，包括在體系開發階段時，采用哪一類的平台、語言和廠家。理論上，你不要修改商業對象，除非是為了維護它們基本的屬性和行為而必須這樣做。 在體系決議的指導下，一個詳細的設計說明應該提到所有類的規范，包括必要的實現屬性，它們詳細的接口和偽代碼或者操作的純文本描述。規范的詳細程度應該達到只要和模型框圖結合，就可得到所有必要的編程信息。在許多自動化的軟件生產流程中，你可以從面向對象的框圖中產生代碼的框架。要注意的是stub和skeleton通常是無需在框圖中展示出來的，因為它們對於設計者和編程者來說都是透明的。我在圖6中包含它們只是為了說明EJB的基本點。
****************圖六************** 在你完成詳細的對象設計後，你就完成了域對象的對象相關映射。這樣做的原因是，雖然面向對象的方法論在目前是比較先進的，不過最流行和持久的商店都是關系型的。此外，一個客戶的IT架構在許多方面都已經反映了現有的投資和商業RDBMS廠家的選擇。因此將域對象模型轉換為關系模型或者數據庫表是非常重要的。有很多容器管理的工具，不過它們不能代替一個好的關系數據庫設計。 V、實現 有了一個好的架構和細節設計，實現將是一個很清晰的任務。此外，由於我們在體系原型階段設計和實現了系統的一個垂直部分，因此在實現階段我們不會碰到很多麻煩事情。在許多公司中，開發者通常都是過早進入實現階段，特別是當經理在監視他們的時候，因為對於他們，做其它的事情等於浪費公司的時間。 結果是，不再花時間來畫UML框圖，而是在代碼開發中測試想法，這要花數星期和幾個月的時間，在這種情形下，所有的體系決議和設計都是在代碼階段作出的，通常要在幾個月後才會發現開發已經進入了一個錯誤的方向。 VI、確認 確認包括有測試以驗證該系統符合設計並且滿足需求。在整個開發周期中，驗證發生在開發和安裝階段。單元測試、集成測試和用戶容忍度測試都是重要的主題
