吳昌雨，王善勤，李云松，劉青，鄒軍國

(滁州職業(yè)技術學院，安徽滁州239000)

引言

傳統的軟件開發(fā)經常是分析與設計割裂的，一個典型的例子就是在我國系統分析師、系統設計師就是兩種不同的職稱，分析與設計分離導致的后果就是分析的結果往往不能直接用于設計編程，設計者需要從分析文檔中給出數據設計逆推出系統的行為，最終造成設計出的軟件并不能真正的體現需求，而領域驅動設計(Domain－Driven Design，DDD)是Eric Evans在其著作《Domain－Driven Design–Tackling Complexity in the Heart of Software》［1］中首次提出的一種用于指導復雜軟件設計與開發(fā)的一整套基于領域模型的系統分析和設計的方法．它將軟件分析與設計的關注點從數據引導到業(yè)務上來，打破了分析與設計的隔閡，提出了領域模型概念，使得軟件能夠適應更靈活的需求變更．

本文從教學資源共享平臺的分析與設計入手，闡述了領域驅動設計的相關理論及其應用，通過應用六邊形架構實現了系統原型，為類似軟件開發(fā)過程中領域驅動設計方法的應用提供借鑒．

1 相關工作

領域驅動設計是面向對象的分析與設計(Object Oriented Analysis Design，OOAD)的擴展和延伸，它既是面向對象設計的補充，又完成了對面向對象設計的超越，相對OOAD而言，它的主要變化在于能夠使用領域模型準確反應業(yè)務語言，也正因為此，它幾乎成了目前開發(fā)大中型復雜軟件系統的主流方法．國內外研究學者對領域驅動設計的核心構成要素如分層架構、實體、值對象服務等概念展開了大量研究．例如Vaughn Vernon的《Implementing Domain－Driven Design》(實現領域驅動設計)從戰(zhàn)略設計高度研究了包括領域、實體、值對象、受限上下文等概念如何設計，并從戰(zhàn)術設計的角度研究了其如何實施［2］;Mat Wall等人從Guardian．co．uk網站，采用領域驅動設計后其架構演進的角度著手分析了如何在既有項目上應用領域驅動設計并不斷演進［3］;Jimmy Nilsson在其著作《Applying domain－driven design and patterns》(領域驅動設計與模式實戰(zhàn))中，展示了如何應用測試驅動開發(fā)(TDD)不斷改進領域驅動設計以及應用領域驅動設計創(chuàng)建高質量企業(yè)級應用架構的過程［4］．

2 領域驅動建模及架構設計

2．1 構建領域模型

和傳統軟件開發(fā)一樣，軟件開發(fā)首先是從軟件專家與項目領域專家的交流開始，但這種交流通常會存在障礙，原因是雙方思維方式及問題的側重點是不一致的，所以領域驅動設計的一個核心的原則就是使用一種基于模型的通用語言(Ubiquitous Language)實現相互的交流．圖1展示了通用語言是介于開發(fā)者與領域專家組成的開發(fā)團隊所使用的用于統一其行動及幫助創(chuàng)建統一模型的語言．

圖1 構建通用語言

以教學資源共享平臺開發(fā)為例，首先由領域專家對其需求進行定義:教師可以創(chuàng)建并管理課程;課程由章節(jié)構成，每個章節(jié)包括一定學時的教學內容;章節(jié)中的教學內容由文檔、視頻、音頻等教學資源構成;學生可以瀏覽并收藏課程內容．

如果是使用傳統的面向對象程序設計方法，根據其需求可以由動名詞法得到一些實體類，類之間包含一些屬性及其get/set方法，這些實體類的作用很單一，僅僅用于描述實體卻沒有任何與其業(yè)務邏輯相關的東西，業(yè)務邏輯將會被放到一個單獨的service類中處理，這是一種典型的失血模型．而采用領域驅動設計方法則要求將業(yè)務邏輯集中于領域對象中，同樣是上面的例子，課程領域模型可以被視為一個聚合，課程作為聚合根包含了章節(jié)與課程資源，聚合根內部包含有狀態(tài)，并且這種狀態(tài)不能直接暴露出去，另外聚合內部的對象通過聚合根實體與外界交互．因此從邏輯上得出這樣一個結論:教師、學生作為用戶與課程發(fā)生業(yè)務邏輯，而課程作為聚合根其內部包含了章節(jié)及教學資源，即形成了圖2所示的領域模型．

圖2 教學資源共享平臺領域模型

這種領域模型準確的反應了業(yè)務，業(yè)務邏輯不是放在單獨的業(yè)務邏輯類中處理，而是包含在領域對象中，每個領域對象都是包含了屬性與業(yè)務邏輯相對完整的獨立體，并與現實領域中的業(yè)務對象一一映射．領域模型則是由這些領域對象組成．這種設計方法，即保證了系統的可維護性、擴展性和復用性，同時也在處理復雜業(yè)務邏輯方面具有先天優(yōu)勢．

2．2 架構設計

Eric Evans在《領域驅動設計》中給出了一個典型的四層參考架構，分別是用于展示信息，并解釋用戶命令的表現層;起到協調、調度作用的應用層;核心的領域層，包括業(yè)務領域的信息，以及業(yè)務對象的狀態(tài)變更;提供業(yè)務對象的持久化等支撐的基礎設施層．

這種分層架構很好的遵循了關注點分離的原則，對領域對象進行了明確的策略和職責劃分，讓領域對象和現實世界中的業(yè)務形成良好的映射關系，相比于傳統的軟件架構分層有如下特點:

1)應用層不包含業(yè)務邏輯，由領域層處理具體的業(yè)務操作

傳統三層架構軟件設計中，有專門用于處理業(yè)務邏輯的業(yè)務邏輯層(BLL)，在這樣的架構中，隨著需求的變更業(yè)務邏輯處理類開始積聚越來越多的業(yè)務邏輯，而領域對象則成為單純的數據載體造成了“肥的服務層”和“貧血的領域模型”．而在DDD方法指導下，領域模型應該側重于具體的業(yè)務操作領域．領域對象由實體和值對象構成，實體類具備自己的屬性和行為、狀態(tài)，可以聚合，實體類之間可以有聚合關聯等關系，可以借由基礎設施層進行持久化．

2)領域層不依賴于實現的細節(jié)，層與層之間松耦合

在軟件分層結構中，層通常是職責劃分為獨立且緊密結合的單元，比如傳統三層架構中BLL層負責業(yè)務邏輯，它依賴于底層數據訪問層的支持同時也為其上級表示層提供依賴，這種層與層之間的依賴關系看起來很自然，但在具體面對需求變化時，每一個層次的變更都有可能影響到其他層，并對系統的伸縮性產生負面影響．而在DDD中，領域層雖然負責處理整個系統的業(yè)務邏輯，但其設計是與其他層松耦合，即與其上下層之間沒有依賴關系，領域模型業(yè)務邏輯的實現應該獨立于持久化實現的細節(jié)．

事實上，DDD的具體實現并不依賴于特定架構，包括其參考架構的層次概念在實踐中都是可以忽略的，本文針對教學資源共享平臺采用了圖3所示的六邊形架構(Hexagonal architecture)，圖中左邊是六邊形架構，右邊是資源共享平臺實現過程中針對六邊形架構的一些具體實現．

圖3 六邊形架構

這種六邊形架構也可以稱之為端口和適配器架構(Ports and Adapters architecture)［5］，該架構設計目標是實現層次之間的解耦，在其核心的領域模型中包含了所有的業(yè)務邏輯與規(guī)則(但并不直接實現，由基礎設施層通過DI注入);包圍領域模型的是應用程序端口層，它負責接收請求，并交由領域層處理，這一層很薄，主要起到協調作用;最外層的是適配器層，負責以某種格式接受輸入并產生輸出，比如通過HTTP接受客戶端請求并封裝為端口能夠理解的方式交給端口，再將處理結果轉換為HTTP相應反饋給客戶端．該架構的特點是組件與組件之間是相互平等的，模糊了層次概念，因為各層次之間的交互并不依賴于各自于實現的細節(jié)，都是通過接口實現，這一特性的實現取決與軟件抽象及一些新技術手段的運用．具體來說，該架構的實現需要以下三種技術手段的配合:

1)OOP(Object Oriented Programming，面向對象編程)，OOP仍然是領域實現中的重要原則，應充分利用其封裝、繼承、接口等特性設計領域對象;

2)DI((Dependency Injection，依賴注入)，DDD要求領域對象既要具有業(yè)務邏輯但又不能依賴于具體實現細節(jié)，則只能通過DI的方式將數據持久化等業(yè)務邏輯注入到領域對象中;

3)AOP(Aspect Oriented Programming，面向方面編程)，AOP可以很好的實現關注點橫切，比如可以使用AOP將領域對象的業(yè)務規(guī)則檢查、狀態(tài)變化跟蹤、數據緩存、事務管理等某個方面的問題從領域對象中移除出來，讓領域對象更好的關注業(yè)務．

3 教學資源共享平臺設計實現

3．1 領域層設計實現

領域對象由實體及值對象構成，實體(Entities)類具有唯一的ID，能夠實現持久化等業(yè)務邏輯，對應于現實世界中的業(yè)務對象，在系統中設計了Course等實體類;值對象無ID，由對象屬性描述，可用于傳遞數據或對實體進行補充描述．

基于領域模型，教學資源共享平臺的通過設計與分析教學資源共享平臺領域層設計圖如圖4所示:

圖4 教學資源共享平臺領域建模

圖中領域對象和現實業(yè)務的對應關系為:Teacher——教 師、Student——學 生、Course——課程、Lesson——教學章節(jié)、Resource——教學資源．這5個領域對象按照功能劃分為兩個模塊，分別是用戶模塊和課程模塊，將這些高關聯度的類劃分到一個模塊，可以提供盡可能大的內聚性，從圖3中可以看出每個模塊通過一個定義好的接口被其他的模塊訪問，比如用戶模塊通過IUserService接口的實現類UserService服務與外部交互，其目的是降低系統耦合度．UserService以及CourseService都屬于DDD中的領域服務，它為外部提供操作接口，負責對領域對象進行調度與封裝并提供各種形式的服務，服務執(zhí)行的操作代表了一個領域概念，被執(zhí)行的操作通常會涉及到領域中的其他對象，以刪除課程為例，該業(yè)務邏輯不僅僅需要刪除課程還需考慮如何處理與其相關聯的章節(jié)及教學資源，此時將業(yè)務邏輯放到服務中是一種更合理的做法．

在領域對象設計過程中還應該處理好對象之間的關系，通常領域對象之間會相互產生各種聯系，甚至形成一個復雜的關系網，比如在教學資源共享平臺中一門課程擁有多個教學章節(jié)，這是一個典型的一對多關系;一位老師可以創(chuàng)建多門課程應該也是一個一對多關系，但同樣的一對多關系在設計過程中還應區(qū)別對待，對DDD中的領域模型而言，其設計目標并非讓其具備完整的關聯關系，而是盡量的簡化關系．復雜的關聯關系只會讓管理對象生命周期變得困難，簡化關系可以采取刪除非基本關聯關系、添加約束減少多重性、雙向關聯轉為單項關聯等手段實現．教學資源共享平臺的開發(fā)采用了Groovy語言，以Course領域對象設計為例，其代碼如下:

代碼中展示了Course與Lesson之間的一對多關系，因為Course與Lesson之間業(yè)務上緊密相連，其關系應在模型中體現．但在Course與Teacher之間的關系的處理上，考慮到邏輯上他們分屬兩個不同的模塊，Course領域對象中維護其關系將導致額外的復雜性，因而并未在Course領域對象中直接體現兩者之間的關系，而是通過teacherID維護其關聯關系，另外在代碼中通過設置約束來維護其關聯關系的完整性，比如定義一個約束用來保證只有課程的創(chuàng)建者才可以執(zhí)行課程的維護，代碼如下:

def isCourseOwner(Teacher teacherInstance，Course courseInstance){

return courseInstance．teacher．id．equals(teacher-Instance．id)

}

在進行刪除、修改等操作之前需要先調用該方法確認當前操作者與課程中TeacherID一致才可以繼續(xù)進行．

3．2 應用程序端口層設計實現

包圍領域模型的是應用程序端口層它負責接收請求，并交由領域層處理，這一層很薄，主要起到協調作用．

3．3 適配器層與基礎設施層

適配器層是最外部的一層，它包含了與各種外部設備對接的適配器，比如針對Web瀏覽器用戶的適配器、針對數據庫交互的適配器、針對外部服務的適配器、甚至包括針對自身內部操作的適配器等，這些適配器有些需要自行開發(fā)也有些可以利用基礎實施層的一些中間件來實現其功能．

教學資源共享平臺的基礎設施層主要利用了一些JavaEE開源組件來構建，其中包括Hibernate實現數據持久化;Spring MVC框架實現IOC及AOP;JDBC實現數據庫驅動等．

4 結論

采用領域驅動設計的最大優(yōu)勢是直接將核心業(yè)務邏輯與領域模型結合起來，而不用向傳統軟件設計那樣分割為數據與行為，這種優(yōu)勢使其在復雜軟件設計中已成為主流思想，基于其設計教學資源共享平臺充分應用了領域驅動設計方法的相關理論，在其四層參考架構的基礎上研究了基于六邊形架構的具體實現，模糊了分層概念，更為充分的體現了軟件設計中高內聚、低耦合的要求．

［1］Eric Evans．Domain－Driven Design［M］．Boston:Addison－Wesley Professional，2003．

［2］Vaughn Vernon．Implementing Domain－Driven Design［M］．Boston:Addison－Wesley Professional，2013．

［3］Mat Wall，Nik Silver．演進架構中的領域驅動設計．［EB/OL］．王麗娟譯．http://www．infoq．com/cn/articles/ddd－evolving－architecture．2009．

［4］Jimmy Nilsson．領域驅動設計與模式實戰(zhàn)［M］．趙俐，馬燕新，譯．北京:人民郵電出版社，2009．

［5］Alistair Cockburn．Hexagonal architecture．［EB/OL］．http://alistair．cockburn．us/Hexagonal+architecture．2010．