我研究領域驅動設計已經近年時間了在這年裡我從了解領域驅動設計的基本思想開始系統地學習了與領域驅動設計相關的概念開發模式以及應用系統架構風格並將其運用在了實際的項目架構與開發中
我研究領域驅動設計已經近年時間了在這年裡我從了解領域驅動設計的基本思想開始系統地學習了與領域驅動設計相關的概念開發模式以及應用系統架構風格並將其運用在了實際的項目架構與開發中在此之前我一直被一些應用程序架構設計上的問題所困擾比如在數據持久層如何讓數據持久化機制能夠支持不同的數據庫類型甚至是非關系型數據庫如何能夠讓開發人員將關注點放在領域模型上而在更改領域模型的同時不用去關心數據持久化的細節內容如何將應用程序的視圖模型部署在服務器端而客戶端可以通過不同的用戶界面代理產生不同的視圖展示機制等等為了實現設計思想我於年開發了一套基於類似XUP協議的應用框架原型在客戶端通過WCF技術與服務器進行通信以支持服務端事件的響應與處理而數據訪問部分則采用NHibernate的SchemaTools在服務每次啟動的時候比對領域模型與數據庫的差異從而動態調整數據庫結構整個系統的運行機制有點類似ASPNET但它可以支持諸如WindowsFormsWPF等多種用戶界面機制（如圖一）在完成了第一階段的原型開發後我在《計算機工程與應用》期刊上發表了一篇題為《基於XML的松耦合UI架構的設計與實現》的論文闡述了這個應用框架的設計與開發的要點與細節
遺憾的是我並沒有真正地完成這個框架的開發首先在基礎結構層使用NHibernate的SchemaTools來完成數據庫的同步過程會產生很多限制比如自動化的數據庫結構變更會出現很多冗余信息數據庫必須采用關系型數據庫框架本身需要依賴於一套特定的機制才能實現其功能ORM具有一定程度的性能損耗於是應用程序就會產生性能調優的瓶頸其次沒有對領域模型的設計與開發做出很好的支持整個框架更多地是在技術層面為應用程序的開發提供便捷忽視了領域模型的重要性這就使得整個框架沒有一個清晰的思路去解決數據映射與傳輸方面的問題再次雖然框架已經實現了基於XML的界面描述事件綁定事件樁與事件路由等基本特性但與成熟的框架相比還是有很大的差距而彌補這樣的差距還需要花費很大的努力比如資源管理系統基於角色的權限管理系統商業許可證的授權方式與支持系統報表管理系統基於LUA或Javascript的客戶端事件處理系統等等而這所有的內容都不是光靠我一個人所能完成的總之從技術架構上看除了能夠支持多種用戶界面機制外整個框架跟ASPNET很相似
然而在設計與實現這個框架原型的過程中我思考了很多也學到很多隨著領域驅動設計思想的引入我慢慢地在思考領域模型能否以DTO的形態出現在應用層？倉儲是領域概念但如果真正將其實現在領域層則明顯不合適因為它需要與外部技術架構打交道但如果設計在基礎結構層由於倉儲是直接對領域對象進行操作的那麼從NET的開發上來看基礎結構層的程序集就必須引用領域模型的程序集於是領域模型就無法去引用基礎結構層的程序集因為會產生循環引用因此也就無法去使用基礎結構層的服務了像這樣的問題又如何解決？在領域模型中領域對象能直接操作倉儲來完成業務邏輯嗎？應用層的作用是任務協調而任務又包含哪些內容？協調又是怎樣的一個過程？應用層與用戶界面層通信是通過數據傳輸對象（DataTransferObjectDTO）實現的那麼是否需要為每一個領域對象設計一個DTO如果是的話那豈不是開發過程會變得非常繁雜而且會降低應用程序的可維護性比如今後如果領域模型發生了更改那麼也需要相應地更改DTO更進一步是否在領域層與基礎結構層的數據訪問組件之間也需要引入類似DTO的概念以便解耦領域模型與數據模型？但如果的確如此的話那系統中豈不是充斥著各種各樣的數據對象？這是基於領域驅動設計的軟件架構的最佳實踐嗎？
只有真正地實踐才能很好地回答這些問題於是我開始結合ADONETEntityFramework來實踐領域驅動的軟件架構並結合自己的收獲總結了《EntityFramework之領域驅動設計實踐》系列文章發表在了博客園上該系列文章獲得了博客園社區讀者的廣泛關注很多朋友紛紛參與討論並提出了不少針對性很強的問題我也盡我自己的最大努力盡量做到有問必答於是通過反反復復的討論與相關知識的慢慢積累一種面向領域驅動的軟件架構設計方式已經在我腦海裡成型了並且在實踐過程中自己總結了一些哪些方式是可行的哪些方法是不合理的基於領域驅動的軟件架構設計最佳實踐
之後我開始著手把我所總結的這些內容實現在一個應用程序開發框架上使得軟件人員能夠非常方便快捷地開發出基於領域驅動的軟件架構的應用程序我將這個框架取名為Apworks（ApplicationDevelopmentFrameworkandTools的縮寫取名其實也是來源於我之前提到的那個未完成的框架名稱）在年底到年初我在微軟的開源網站codeplex上簽入了Apworks的第一份代碼而在年底成功完成了Apworks的Alpha版本與此同時ApworksAlpha版的第一個演示案例TinyLibraryCQRS（tlibcqrs）也在codeplex上發布社區不少朋友對Apworks以及tlibcqrs都非常關注有朋友甚至希望能夠將Apworks整合到他們的項目中在此我對這些朋友們的支持表示衷心感謝
基於NET的框架的設計與開發更不是一件容易的事情這與領域驅動設計相比它又屬於另一個領域我們需要考慮的不是通用語言不是+視圖不是用例不是角色不是DCI不是領域建模我們需要考慮的是如何搭建一個高效的穩定的安全的可擴展的基於NET的應用程序開發框架而這些就是本文所要重點討論的內容
本文將分為兩大部分第一部分重點討論基於NET的框架架構設計的設計指南與最佳實踐這部分內容都是我在設計與實現Apworks框架的過程中結合一些理論知識總結出來的比如如何使用分離接口模式以減小框架本身與第三方組件之間的依賴如何提高框架的可測試性等這部分內容還將給出幾個常用的設計模式體系結構模式和語言慣用法的NET（C#）實現以便讀者們在構建自己的應用程序開發框架時可以在需要的時候直接引用本文給出的模式實現方式提高開發效率當然這些內容都是我的經驗總結或許會因為我能力有限而出現疏漏或不合理的現象這就需要讀者朋友們給出意見給予指正了我也會跟進這些反饋信息而不定期地修訂原文第二部分將以Apworks為例詳細講解Apworks框架中某些組件的設計構想例如在設計外部事件存儲（EventStore）的時候我是如何考慮並實現存儲機制的技術無關性的又比如快照提供者（SnapshotProvider）是如何支持可擴展的基於不同策略的快照功能實現機制這些內容將在這部分進行討論
總之本文將主要討論基於NET的應用程序框架架構設計實踐在此過程中會引用Apworks框架作為案例進行講解選用Apworks作為案例首先是因為本文所討論的所有內容都來源於該框架的設計與開發過程中其次Apworks已經是一個現成的框架了讀者朋友在學習的過程中可以有個成品作參考以便更好地理解本文所討論的內容希望讀者朋友不會誤認為本文是Apworks的廣告而對之產生反感我真心希望本文能夠給愛好企業級應用系統架構的朋友帶來一定的參考價值
From:http://tw.wingwit.com/Article/program/net/201311/13581.html
