本文是我學習Scott Millett & Nick Tune編著的《領域驅動設計模式、原理與實踐》一書的學習筆記,一共會分爲4個部分以下,此文爲第1部分:html
① 領域驅動設計的原則與實踐數據庫
② 戰略模式:在有界上下文之間通訊設計模式
③ 戰術模式:建立有效的領域模型架構
④ 有效應用程序的設計模式框架
腦圖瀏覽:https://www.processon.com/view/5cb49b14e4b0a13c9de1042d#map微服務
這一章主要介紹了DDD是什麼,強調DDD是一種開發思想體系,它是模式(戰略模式、戰術模式)、原則和實踐的集合,能夠被應用到軟件設計中以管理複雜性。工具
DDD並不是一種模式語言,它是專一於交付的一種協做思想體系,其中通訊起核心做用,而要高效通訊,就須要使用公共語言。學習
DDD會將側重點放在如下幾個方面:網站
更爲重要的是,不要認爲DDD是一套框架,DDD也不是銀彈或靈丹妙藥,不可在項目中小題大作!編碼
下圖展現了一個演進的領域驅動設計過程:
From:張逸《領域驅動戰略設計實踐》課程
這裏摘抄一段張逸老師在《領域驅動戰略設計實踐》課程中的話:
面對客戶的業務需求,由領域專家與開發團隊展開充分的交流,通過需求分析與知識提煉,以得到清晰的問題域。經過對問題域進行分析和建模,識別限界上下文,利用它劃分相對獨立的領域,再經過上下文映射創建它們之間的關係,輔以分層架構與六邊形架構劃分系統的邏輯邊界與物理邊界,界定領域與技術之間的界限。以後,進入戰術設計階段,深刻到限界上下文內對領域進行建模,並以領域模型指導程序設計與編碼實現。若在實現過程當中,發現領域模型存在重複、錯位或缺失時,再進而對已有模型進行重構,甚至從新劃分限界上下文。
兩個不一樣階段的設計目標是保持一致的,它們是一個連貫的過程,彼此之間又相互指導與規範,並最終保證一個有效的領域模型和一個富有表達力的實現同時演進。
腦圖地址:https://www.processon.com/view/5cb5e474e4b0841b84327187#map
這一章主要介紹了什麼是知識提煉,知識提煉是一個持續協做達成共識以建立有用模型的過程,而如何實踐好這個過程,介紹了一些最佳實踐:好比專一於最有意思的對話、從用例開始、提出有力的問題等等。
而對於不須要構建新模型的人來講,研究現有模型也是有技巧的,我的感觸最深的就是要真正理解意圖,也就是不要盲從於客戶的需求,由於這個需求極可能並不能真正地解決問題和創造價值,每每須要更深層次地理解隱含的願景而且可以認識到業務到底試圖達到什麼。影響地圖和業務模型是兩個經典的實踐方法,書中的例子在線運動裝備運營商的業務模型圖也比較經典。
腦圖瀏覽地址:https://www.processon.com/view/5cba8957e4b059e20a0068c8#map
這一章主要介紹了核心領域,在一個大的問題空間中會同時存在不少的小問題域,而這些小問題域每每只有少部分是核心領域,其餘的可能都是通用域和支撐域。核心域是咱們軟件的根本競爭力所在,所以也能夠說是咱們編寫軟件的緣由。拿一個在線拍賣網站來講,能夠見下圖所示劃分了核心域、支撐域和通用域:
對於核心域,咱們須要配備最好的開發人員專一於此。對於支撐域,咱們能夠外包開發或者配備初級開發人員,可是要確保支撐域中的模型足夠好。而對於通用域,若是能夠,咱們能夠尋求購買現成解決方案。
腦圖瀏覽地址:https://www.processon.com/view/5cbaa844e4b01941c8b441d2
這一章主要介紹了模型驅動設計和通用語言的重要性,模型驅動設計是將分析模型(業務模型)綁定到代碼實現模型並確保這兩個模型保持協同並可用的過程。
模型驅動設計專一於實現以及對於初始模型可能須要修改的約束,領域驅動設計則專一於語言、協做和領域知識,他們是一個彼此互補的關係。而要實現協做,就須要使用通用語言,藉助通用語言能夠將分析模型和代碼模型綁定在一塊兒,並最終實現團隊建模。實踐UL是一個持續的過程,多個迭代後會不斷對UL進行驗證和改進,以便實現更好的協做。
因爲時間和精力都有限,只有僅僅爲核心域應用模型驅動設計和建立UL才能帶來最大的價值,而不須要將這些實踐應用到整個應用程序之中。
腦圖瀏覽地址:https://www.processon.com/view/5cbab6c5e4b06bcc13844497
這一章主要介紹了領域層的概念及做用,下圖展現領域層在在整個應用程序代碼中的位置,領域層的最大做用就在於隔離領域模型的複雜性和應用程序的技術複雜性。
在領域建模時能夠遵循的設計模式,Martin Fowler在《企業應用架構模式》一書中提出瞭如下幾種:
腦圖瀏覽地址:https://www.processon.com/view/5cbad3dee4b09a3e45a3fbc6
一般狀況下,嘗試將單個模型用於複雜問題域一般會致使代碼變成大泥球,並且會增長團隊之間的協做成本並下降交付業務價值的效率。有界上下文就是劃分和破除這種大模型的有效方式,一個有界上下文就是一個語言邊界,它能夠隔離模型以免領域術語在不一樣上下文中的歧義。而咱們經常提到的微服務,我的感受更像是有界上下文的一種技術實現途徑之一,有界上下文中具備較高的自主性,擁有從展示層、領域邏輯層再到持久化層的完整代碼堆棧,正應對了咱們的每個微服務的應用程序,也具備較高的獨立性,擁有本身的數據庫和一套完成的垂直切片的架構模式。
書中還提到一個重要的觀點,那就是「並不是全部有界上下文都共享相同的架構模式」,換句話說就是能夠將不一樣的架構模式應用到不一樣的有界上下文中。想一想這年來的企業應用架構模式的發展,已經從單一的架構風格發展爲了混合式的架構風格了,就微軟的大DEMO項目eShopOnContainers而言,也具備多種架構風格(簡單的數據驅動CRUD+簡化的分層DDD等),以下圖所示:
所以,咱們也不該該侷限在某一種或者兩種架構模式上,而是應該量身應用,沒有複雜性業務邏輯的微服務,那就應該KISS(Keep It Simple & Stupid),不然就能夠考慮DDD。
腦圖瀏覽地址:https://www.processon.com/view/5cbc3240e4b0bab909613768
上下文映射用來捕獲各個有界上下文之間的技術與組織關係,它最大的做用就是保持模型的完整性。張逸老師在《領域驅動戰略設計實踐》課程中提到,在戰略設計階段,針對問題域,經過引入限界上下文和上下文映射能夠對問題域進行合理的分解,識別出核心領域和子領域,並肯定領域的邊界以及他們之間的關係,從而維持模型的完整性。
限界上下文不只侷限於對領域模型的控制,而在於分離關注點以後,使得整個上下文能夠成爲獨立部署的設計單元,這就是咱們很是熟悉的「微服務」的概念;而上下文映射的諸多模式則對應了微服務之間的協做。
腦圖瀏覽地址:https://www.processon.com/view/5cc1cbe4e4b0841b84400fc9
這一章討論了應用程序架構、服務和客戶端,惟一記住的只有一句:「DDD不須要特殊的架構,只要是能將技術問題與業務問題分離的架構便可」。
腦圖瀏覽地址:https://www.processon.com/view/5cc46afbe4b08b66b9bd9513
DDD的戰術模式雖然能夠指導咱們建立有效領域模型,但這並不是DDD的真正價值所在。由於,DDD其實並不是編碼這麼簡單,與領域專家的協做以進行知識提煉,以及在通用語言中表述的問題域達成共識才是DDD的支柱。
在現實中,團隊在應用DDD時一般會低估應用DDD的成本,應用DDD須要一個願意學習該領域的聰明專一的團隊,還須要領域專家的參與,沒有他們,團隊就沒法揭示更深層的看法。
腦圖瀏覽地址:https://www.processon.com/view/5cc5568be4b059e20a0bc1e1
DDD不是靈丹妙藥,更不是「銀彈」,張逸老師說道:請事先下降對領域驅動設計的不合現實的指望,要學會運用設計原則去解決問題,而非所謂的「設計規範」。更爲重要的是,僅僅在須要時應用DDD原則,不要將其用做解決全部問題的工具。
整體來講,這一章比較高屋建瓴,總結性的內容偏多,但對於沒有多少實戰經驗的人來講,閱讀完不會有太深入的印象。不過,這並不影響,後續就是戰略設計和戰術設計的部分了,相信會隨着學習的深刻,再反過來看這些原則和實踐會有更多的認識。
Scott Millett & Nick Tune,《領域驅動設計模式、原理與實踐》
在同事的推薦下,開始學習張逸老師的《領域驅動戰略設計實踐》課程,配合《領域驅動設計模式、原理與實踐》一書共同窗習DDD,感受會比單看書好不少,也在此推薦一下張逸老師的這門課,五月份立刻會出《領域驅動戰術設計實踐》,值得期待。
原文出處:https://www.cnblogs.com/edisonchou/p/edc_ddd_foundation_study_part1.html