我研究領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)已經(jīng)近4年時(shí)間了，在這4年里，我從了解領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的基本思想開(kāi)始，系統(tǒng)地學(xué)習(xí)了與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)相關(guān)的概念、開(kāi)發(fā)模式以及應(yīng)用系統(tǒng)架構(gòu)風(fēng)格，并將其運(yùn)用在了實(shí)際的項(xiàng)目架構(gòu)與開(kāi)發(fā)中。在此之前，我一直被一些應(yīng)用程序架構(gòu)設(shè)計(jì)上的問(wèn)題所困擾，比如：在數(shù)據(jù)持久層，如何讓數(shù)據(jù)持久化機(jī)制能夠支持不同的數(shù)據(jù)庫(kù)類(lèi)型，甚至是非關(guān)系型數(shù)據(jù)庫(kù)；如何能夠讓開(kāi)發(fā)人員將關(guān)注點(diǎn)放在領(lǐng)域模型上，而在更改領(lǐng)域模型的同時(shí)，不用去關(guān)心數(shù)據(jù)持久化的細(xì)節(jié)內(nèi)容；如何將應(yīng)用程序的視圖模型部署在服務(wù)器端，而客戶(hù)端可以通過(guò)不同的用戶(hù)界面代理產(chǎn)生不同的視圖展示機(jī)制，等等。為了實(shí)現(xiàn)設(shè)計(jì)思想，我于2008年開(kāi)發(fā)了一套基于類(lèi)似XUP協(xié)議的應(yīng)用框架原型，在客戶(hù)端通過(guò)WCF技術(shù)與服務(wù)器進(jìn)行通信，以支持服務(wù)端事件的響應(yīng)與處理，而數(shù)據(jù)訪(fǎng)問(wèn)部分則采用NHibernate的Schema Tools，在服務(wù)每次啟動(dòng)的時(shí)候比對(duì)領(lǐng)域模型與數(shù)據(jù)庫(kù)的差異從而動(dòng)態(tài)調(diào)整數(shù)據(jù)庫(kù)結(jié)構(gòu)。整個(gè)系統(tǒng)的運(yùn)行機(jī)制有點(diǎn)類(lèi)似ASP.NET，但它可以支持諸如Windows Forms、WPF等多種用戶(hù)界面機(jī)制（如圖一）。在完成了第一階段的原型開(kāi)發(fā)后，我在《計(jì)算機(jī)工程與應(yīng)用》期刊上發(fā)表了一篇題為《基于XML的松耦合UI架構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)》的論文，闡述了這個(gè)應(yīng)用框架的設(shè)計(jì)與開(kāi)發(fā)的要點(diǎn)與細(xì)節(jié)。

　　遺憾的是，我并沒(méi)有真正地完成這個(gè)框架的開(kāi)發(fā)。首先，在基礎(chǔ)結(jié)構(gòu)層，使用NHibernate的Schema Tools來(lái)完成數(shù)據(jù)庫(kù)的同步過(guò)程，會(huì)產(chǎn)生很多限制，比如：自動(dòng)化的數(shù)據(jù)庫(kù)結(jié)構(gòu)變更會(huì)出現(xiàn)很多冗余信息，數(shù)據(jù)庫(kù)必須采用關(guān)系型數(shù)據(jù)庫(kù)，框架本身需要依賴(lài)于一套特定的機(jī)制才能實(shí)現(xiàn)其功能，ORM具有一定程度的性能損耗，于是應(yīng)用程序就會(huì)產(chǎn)生性能調(diào)優(yōu)的瓶頸；其次，沒(méi)有對(duì)領(lǐng)域模型的設(shè)計(jì)與開(kāi)發(fā)做出很好的支持，整個(gè)框架更多地是在技術(shù)層面為應(yīng)用程序的開(kāi)發(fā)提供便捷，忽視了領(lǐng)域模型的重要性，這就使得整個(gè)框架沒(méi)有一個(gè)清晰的思路去解決數(shù)據(jù)映射與傳輸方面的問(wèn)題；再次，雖然框架已經(jīng)實(shí)現(xiàn)了基于XML的界面描述、事件綁定、事件樁與事件路由等基本特性，但與成熟的框架相比，還是有很大的差距，而彌補(bǔ)這樣的差距還需要花費(fèi)很大的努力，比如：資源管理系統(tǒng)、基于角色的權(quán)限管理系統(tǒng)、商業(yè)許可證的授權(quán)方式與支持系統(tǒng)、報(bào)表管理系統(tǒng)、基于LUA或Javascript的客戶(hù)端事件處理系統(tǒng)等等，而這所有的內(nèi)容都不是光靠我一個(gè)人所能完成的。總之，從技術(shù)架構(gòu)上看，除了能夠支持多種用戶(hù)界面機(jī)制外，整個(gè)框架跟ASP.NET很相似。

　　然而在設(shè)計(jì)與實(shí)現(xiàn)這個(gè)框架原型的過(guò)程中，我思考了很多，也學(xué)到很多。隨著領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)思想的引入，我慢慢地在思考：領(lǐng)域模型能否以DTO的形態(tài)出現(xiàn)在應(yīng)用層？倉(cāng)儲(chǔ)是領(lǐng)域概念，但如果真正將其實(shí)現(xiàn)在領(lǐng)域?qū)觿t明顯不合適，因?yàn)樗枰c外部技術(shù)架構(gòu)打交道，但如果設(shè)計(jì)在基礎(chǔ)結(jié)構(gòu)層，由于倉(cāng)儲(chǔ)是直接對(duì)領(lǐng)域?qū)ο筮M(jìn)行操作的，那么從.NET的開(kāi)發(fā)上來(lái)看，基礎(chǔ)結(jié)構(gòu)層的程序集就必須引用領(lǐng)域模型的程序集，于是，領(lǐng)域模型就無(wú)法去引用基礎(chǔ)結(jié)構(gòu)層的程序集，因?yàn)闀?huì)產(chǎn)生循環(huán)引用，因此也就無(wú)法去使用基礎(chǔ)結(jié)構(gòu)層的服務(wù)了，像這樣的問(wèn)題又如何解決？在領(lǐng)域模型中，領(lǐng)域?qū)ο竽苤苯硬僮鱾}(cāng)儲(chǔ)來(lái)完成業(yè)務(wù)邏輯嗎？應(yīng)用層的作用是任務(wù)協(xié)調(diào)，而任務(wù)又包含哪些內(nèi)容？協(xié)調(diào)又是怎樣的一個(gè)過(guò)程？應(yīng)用層與用戶(hù)界面層通信是通過(guò)數(shù)據(jù)傳輸對(duì)象（Data Transfer Object，DTO）實(shí)現(xiàn)的，那么是否需要為每一個(gè)領(lǐng)域?qū)ο笤O(shè)計(jì)一個(gè)DTO，如果是的話(huà)，那豈不是開(kāi)發(fā)過(guò)程會(huì)變得非常繁雜，而且會(huì)降低應(yīng)用程序的可維護(hù)性，比如今后如果領(lǐng)域模型發(fā)生了更改，那么也需要相應(yīng)地更改DTO。更進(jìn)一步，是否在領(lǐng)域?qū)优c基礎(chǔ)結(jié)構(gòu)層的數(shù)據(jù)訪(fǎng)問(wèn)組件之間也需要引入類(lèi)似DTO的概念，以便解耦領(lǐng)域模型與數(shù)據(jù)模型？但如果的確如此的話(huà)，那系統(tǒng)中豈不是充斥著各種各樣的數(shù)據(jù)對(duì)象？這是基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的軟件架構(gòu)的最佳實(shí)踐嗎？

　　只有真正地實(shí)踐，才能很好地回答這些問(wèn)題。于是，我開(kāi)始結(jié)合ADO.NET Entity Framework來(lái)實(shí)踐領(lǐng)域驅(qū)動(dòng)的軟件架構(gòu)，并結(jié)合自己的收獲總結(jié)了《Entity Framework之領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐》系列文章，發(fā)表在了博客園上。該系列文章獲得了博客園社區(qū)讀者的廣泛關(guān)注，很多朋友紛紛參與討論，并提出了不少針對(duì)性很強(qiáng)的問(wèn)題，我也盡我自己的最大努力，盡量做到有問(wèn)必答。于是通過(guò)反反復(fù)復(fù)的討論與相關(guān)知識(shí)的慢慢積累，一種面向領(lǐng)域驅(qū)動(dòng)的軟件架構(gòu)設(shè)計(jì)方式已經(jīng)在我腦海里成型了，并且在實(shí)踐過(guò)程中，自己總結(jié)了一些“哪些方式是可行的、哪些方法是不合理的”基于領(lǐng)域驅(qū)動(dòng)的軟件架構(gòu)設(shè)計(jì)最佳實(shí)踐。

　　之后，我開(kāi)始著手把我所總結(jié)的這些內(nèi)容實(shí)現(xiàn)在一個(gè)應(yīng)用程序開(kāi)發(fā)框架上，使得軟件人員能夠非常方便快捷地開(kāi)發(fā)出基于領(lǐng)域驅(qū)動(dòng)的軟件架構(gòu)的應(yīng)用程序。我將這個(gè)框架取名為Apworks（Application Development Framework and Tools的縮寫(xiě)，取名其實(shí)也是來(lái)源于我之前提到的那個(gè)未完成的框架名稱(chēng)）。在2009年底到2010年初，我在微軟的開(kāi)源網(wǎng)站codeplex上簽入了Apworks的第一份代碼，而在2010年底，成功完成了Apworks的Alpha版本，與此同時(shí)，Apworks Alpha版的第一個(gè)演示案例TinyLibrary CQRS（tlibcqrs）也在codeplex上發(fā)布，社區(qū)不少朋友對(duì)Apworks以及tlibcqrs都非常關(guān)注，有朋友甚至希望能夠?qū)pworks整合到他們的項(xiàng)目中，在此，我對(duì)這些朋友們的支持表示衷心感謝。

　　基于.NET的框架的設(shè)計(jì)與開(kāi)發(fā)更不是一件容易的事情，這與“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”相比，它又屬于另一個(gè)領(lǐng)域：我們需要考慮的不是通用語(yǔ)言，不是4+1視圖，不是用例，不是角色，不是DCI，不是領(lǐng)域建模；我們需要考慮的是如何搭建一個(gè)高效的、穩(wěn)定的、安全的、可擴(kuò)展的、基于.NET的應(yīng)用程序開(kāi)發(fā)框架。而這些，就是本文所要重點(diǎn)討論的內(nèi)容。

　　本文將分為兩大部分，第一部分重點(diǎn)討論基于.NET的框架架構(gòu)設(shè)計(jì)的設(shè)計(jì)指南與最佳實(shí)踐，這部分內(nèi)容都是我在設(shè)計(jì)與實(shí)現(xiàn)Apworks框架的過(guò)程中，結(jié)合一些理論知識(shí)總結(jié)出來(lái)的，比如如何使用分離接口模式以減小框架本身與第三方組件之間的依賴(lài)，如何提高框架的可測(cè)試性等；這部分內(nèi)容還將給出幾個(gè)常用的設(shè)計(jì)模式、體系結(jié)構(gòu)模式和語(yǔ)言慣用法的.NET(C#)實(shí)現(xiàn)，以便讀者們?cè)跇?gòu)建自己的應(yīng)用程序開(kāi)發(fā)框架時(shí)，可以在需要的時(shí)候直接引用本文給出的模式實(shí)現(xiàn)方式，提高開(kāi)發(fā)效率。當(dāng)然，這些內(nèi)容都是我的經(jīng)驗(yàn)總結(jié)，或許會(huì)因?yàn)槲夷芰τ邢薅霈F(xiàn)疏漏或不合理的現(xiàn)象，這就需要讀者朋友們給出意見(jiàn)給予指正了，我也會(huì)跟進(jìn)這些反饋信息而不定期地修訂原文。第二部分將以Apworks為例，詳細(xì)講解Apworks框架中某些組件的設(shè)計(jì)構(gòu)想，例如，在設(shè)計(jì)外部事件存儲(chǔ)（Event Store）的時(shí)候，我是如何考慮并實(shí)現(xiàn)存儲(chǔ)機(jī)制的技術(shù)無(wú)關(guān)性的，又比如，“快照提供者（Snapshot Provider）”是如何支持可擴(kuò)展的基于不同策略的快照功能實(shí)現(xiàn)機(jī)制，這些內(nèi)容將在這部分進(jìn)行討論。

　　總之，本文將主要討論基于.NET的應(yīng)用程序框架架構(gòu)設(shè)計(jì)實(shí)踐，在此過(guò)程中會(huì)引用Apworks框架作為案例進(jìn)行講解，選用Apworks作為案例，首先是因?yàn)楸疚乃懻摰乃袃?nèi)容都來(lái)源于該框架的設(shè)計(jì)與開(kāi)發(fā)過(guò)程中，其次，Apworks已經(jīng)是一個(gè)現(xiàn)成的框架了，讀者朋友在學(xué)習(xí)的過(guò)程中可以有個(gè)成品作參考，以便更好地理解本文所討論的內(nèi)容。希望讀者朋友不會(huì)誤認(rèn)為本文是Apworks的廣告而對(duì)之產(chǎn)生反感，我真心希望本文能夠給愛(ài)好企業(yè)級(jí)應(yīng)用系統(tǒng)架構(gòu)的朋友帶來(lái)一定的參考價(jià)值。

it知識(shí)庫(kù)：.NET應(yīng)用框架架構(gòu)設(shè)計(jì)實(shí)踐 - 概述，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。