傳統三層向DDD的轉變：

• 實體見引入合理的關聯。
• 根據需要引入聚合。
• 將DAL命名的類換成Repository命名。
• 將BAL命名的類換成Service。
• 將BAL中的一些職責重構到Domain中。
• 引入Applicaiton層。
• 根據需要引入ViewModel和Mapper。
• 根據需要引入工作單元。
• 小心ORM工具提供的主鍵對映功能。
• 推薦引入IoC容器。
• 推薦引入AOP。

以DDD為開發模式的設計開發步驟：1）分析需求；2）畫出用例圖，系統中各個角色如何使用系統，也包括外部系統如何使用系統，也包括系統中到某個時間點自動啟動的某些功能（此時角色就是時間）；3）針對各個用例圖，就知道了系統使用的各種業務場景，同時也明確了系統的邊界，從而就明確了領域模型的邊界；4）在領域模型的邊界內劃分聚合，找出每個聚合的邊界，找出邊界內的聚合根，實體，值物件；這步是難點。這裡一定不能混淆的一個概念是，領域建模不是以使用者為中心的建模，而是以使用者的需求為中心的建模。所以要努力尋找各種業務概念，切勿將所有行為都設計到User，Employee，Account，等物件上。而應該找出如Order，LeaveRecord，Payment，JobApplication，等業務概念。5）如果是根據經典的DDD領域建模，我們可以接下來分析一些領域服務，領域服務用於協調多個領域物件之間的行為；6）根據領域模型中的聚合根設計對應的倉儲；這步完成就表示領域模型已經完成了。7）對照前面的需求用例，檢查領域模型是否都可以滿足用例中提到的各種業務場景；8）進一步分析領域模型，分析模型中哪些點是和特定系統相關的設計，哪些點可以進一步抽象出通用的領域模型，該通用領域模型可以滿足此類相似系統的核心業務。比如積分系統中，可以抽象出“積分發放/消費”的模型。該模型可以在任何財務或積分系統中使用；9）現在，可以讓有經驗的人檢查一下你設計的領域模型了，也就是如果有可能就進行一下模型Review，確保在寫程式碼之前，模型的正確性。10）對領域模型進行單元測試，單元測試的時候，如果只想測試業務邏輯，可以設計Stub的倉儲；如果想和持久化一起測試，那可以編寫真實的倉儲，如果你是用Hibernate來做資料儲存，可以在此時建立ORM對映檔案和資料庫表；寫完後，編寫測試用例進行單元測試；11）最後實現你的UI層。但是為了讓你的UI層可以不依賴於你的模型設計和測試，可以在UI層編寫他自己需要的ViewModel，然後他在Web Form或Controller或View上只要訪問ViewModel即可。等到你的領域模型完成並測試通過後，把領域模型的資料填充到ViewModel即可；