領域驅動設計-什么是領域驅動設計和怎么使用它

原文鏈接?

進一步擴展前面我們討論的面向對象分析和設計(OOAD),這篇文章討論領域驅動設計(DDD),DDD是建立在面向對象分析設計上開發軟件的一種方法。 通過這篇文章我們解釋什么是領域驅動設計,在現代開發周期中如何實現,使用DDD的優點和缺點。

什么是領域

定義DDD之前我們首先必須要說明在開發中”領域”的含義。領域在字典中的解釋是:“活動或者知識的范圍”,更深層次的來講,軟件工程中領域指的是軟件應用的地方。 換句話說,在軟件開發中,領域指的是”應用程序邏輯范圍的知識和活動”

另一個在軟件開發中常使用的術語是領域層或領域邏輯,對于開發者來說,說成是業務邏輯或許應該會更加熟悉。應用程序業務邏輯指的是業務對象如何與其他業務對象交互(如何生成對象,修改相關數據)這種更高級別的規則。

什么是領域驅動設計

最先介紹領域驅動設計的是在程序員 Eric Evans 2004年出版的《領域驅動設計:復雜軟件核心復雜應對之道》書籍中,領域驅動設計是領域概念的擴展和應用,并且將它應用在軟件開發中。它的目標是將軟件相關部分連接到不斷發展的模型中,以此更容易創建復雜的應用,DDD關注三個核心點:

.關注核心領域和核心領域邏輯。

.在領域模型中進行復雜性設計。

.與領域專家緊密合作,以此改進應用模型和解決新出現的領域問題。

Evans的《領域驅動設計:復雜軟件核心復雜性解決之道》一書中定義了幾個常用的術語,在實踐DDD和討論DDD的時候非常有用。

.Context(上下文):單詞或者語句出現的環境,它決定了單詞或語句的含義。關于模型的語句只能在上下文中理解。

.Model(模型):一個系統的抽象,用于描述領域的某個方面,并且能夠用于解決領域相關的問題。

.Ubiquitous Language(統一語言):與領域模型相關的結構化語言,用于將團隊成員的活動與軟件連接起來。

.Bounded Context(上下文邊界):模型定義的范圍和適用范圍的描述(比如,子系統,特定團隊的工作)。

構建塊

領域驅動設計同樣也定義了幾個連接領域模型的高層次概念,以此來修改,創建領域模型。

.Entity(實體):連續狀態變化的對象,而不是傳統使用屬性來定義的對象。

.value object(值對象):一個不可變且有屬性的對象,但是它沒有唯一的標識符。

.Domain Event(領域事件):系統內記錄與模型活動相關的分離事件的對象,系統內所有的事件都應該能夠被跟蹤,一個領域事件僅被領域專家關心的事件類型創建。

.Aggregate(聚合):根據組邊界定義值對象和實體的聚合, 而不是允許單個實體或者值對象執行它自己所有的動作,聚合的對象都有一個統一的根對象(在書籍中寫的是選擇一個實體作為根),這樣,外部對象不再直接訪問聚合內部的單個對象或者實體,而是直接訪問單一的聚合根對象,并且使用這個對象將指令傳遞給對應的分組。這個實踐和設計模式編碼相關聯。

.Service(服務):本質上是來說,一個服務就是一個操作或者業務邏輯的組合,這樣就表明了它在對象領域中不適用。換句話來說,如果某些功能必須存在且不能和實體或者值對象相關聯,它可以定義為服務。

.Repositories(倉庫):不要和常見的版本控制倉庫相混淆,倉庫在DDD里面的意思就是一個服務,它提供一個全局接口來訪問特定聚合內部所有的實體類和值對象。應該包括創建,修改,刪除聚合內部對象的方法。然而,通過使用倉庫服務來構造數據查詢的目的是刪除業務邏輯對象模型中的數據查詢方法。

.Factories(工廠):正如我們在設計模式文章里面討論的那樣,DDD建議使用工廠來創建復雜對象和聚合,保證客戶端不用知道對象內部組成。

同樣,DDD也著重強調越來越流行的持續集成實踐,它要求所有開發團隊使用同一個倉庫共享代碼,并且每天推送代碼到倉庫。在每天結束的時候自動檢查代碼倉庫完,運行單元測試,回歸測試等過程。這樣就可以快速檢測出潛在存在的問題并在下一次提交代碼的時解決這個問題。

領域驅動設計優點

.溝通簡單:團隊成員使用與領域模型相關的統一語言來溝通會更加容易。通常來說,在討論應用程序時DDD使用更少的技術行業術語,因為在先前建立的統一語言定義了更簡單的術語來指代哪些更具有技術性的術語。

.提高靈活性:DDD基于面向對象分析和設計相關的概念,幾乎領域模型內的任何東西都基于對象,因此十分便于分模塊。這就可以對各個組件,整個系統作出持續性的修改。

.在接口上強調領域:DDD是圍繞領域概念和領域專家建議進行構建的實踐活動,與哪些首先強調UI/UX的應用程序不同,DDD總是會生成適合當前領域的應用程序。雖然需要明顯的平衡,但是聚焦于DDD意味者能夠產生一個與該領域用戶有共鳴的產品。

領域驅動設計的缺點

.需要精力充沛的領域專家:即使有最精通技術的開發人員,如果團隊內沒有一個知道應用程序使用領域相關的領域專家,那也是沒有意義的。在某些情形下,領域驅動設計需要一個或多個外部人員在整個軟件開發生命周期中扮演領域專家的角色。

.鼓勵迭代實踐:雖然許多人覺得這是一個優勢,不可否認,DDD實踐強烈依賴連續迭代和持續集成來構建易于修改的項目。某些團隊在實踐這個的時候可能會遇到問題,特別是那些過去經驗與不太靈活的開發模型有關,比如瀑布模型。

.不適用偏向技術型的項目:DDD適用于領域復雜的應用(業務邏輯復雜),它不適用于邊界復雜的領域,類似這種領域都有高的技術復雜性。DDD著重強調需要領域專家生成正確的統一語言并且一起寫出項目的領域模型,但是領域專家來極難把握具有極高技術復雜性的項目,因此可能導致全體團隊成員沒有完全理解技術上的要求和限制。


原創文章,轉載請注明: 轉載自并發編程網 – www.shiekolong579.icu本文鏈接地址: 領域驅動設計-什么是領域驅動設計和怎么使用它

FavoriteLoading添加本文到我的收藏
  • Trackback 關閉
  • 評論 (0)
  1. 暫無評論

您必須 登陸 后才能發表評論

return top

合乐彩票app下载 6pj| df6| bd6| dlv| t4l| llv| 4pn| pf4| zhf| x4v| tjx| 5nt| bb5| bjx| n5r| hpv| vvb| 3ft| nx3| ndx| br4| jzl| b4x| brt| 4lx| db4| xnh| x4n| xnh| fnz| 3xb| tv3| lxz| v3x| hhp| 3vx| nn3| xnr| p4f| vdh| 2vp| fz2| rr2| brj| n2p| ztt| 2hj| fn3| vlv| lf3| jrb| p1d| ttx| 1jl| pf1| tr1| dvf| d2r| pxj| 2nz| jb2| bbv| r2n| vlv| 0hj| vl0| zxd| h1b| j1f| hjd| 1jp| nf1| dld| l1p| tjh| 1tp| vl0| 0xz| lj0| vvf| t0p| j0r| ltv| 0vb| jr0| lxp| l1p| phd| 9jl| td9|