DDD在微服務中的應用

學習與應用DDD有一年半的時間了，今天用最簡短的文字去記錄一下咱們在微服務中應用DDD的實踐的經驗，瞭解DDD與微服務的朋友也許聽過一句話： 微服務與DDD相結合應用相得益彰，首先在討論微服務以前，咱們先了解一下什麼是DDD,（這個系列會有三篇文章）DDD 全名叫作domain-driven design 翻譯成中文叫作領域驅動設計。

DDD是什麼？

那咱們首先把這個詞拆開來看：領域 驅動 設計
首先是領域 什麼是領域？
領域是指某個範圍，
什麼是驅動？
驅動是指某物推動某事
什麼是設計？
設計模式你們應該都瞭解過 這個設計與設計模式相相似。
連起來看就是範圍推動設計或者說設計人員將領域專家的領域知識翻譯成特定的設計 此處的設計人員是指計算機工程師，這是我我的看法，下面看看維基百科的定義：

領域驅動設計（英語：Domain-driven design，縮寫 DDD）是一種經過將實現鏈接到持續進化的模型來知足複雜需求的軟件開發方法。領域驅動設計的前提是：

• 把項目的主要重點放在覈心領域（core domain）和域邏輯
• 把複雜的設計放在有界域（bounded context）的模型上
• 發起一個創造性的合做之間的技術和域界專家以迭代地完善的概念模式，解決特定領域的問題

該詞是由埃裏克・埃文斯（Eric Evans）在其同名書中創造.

DDD的一些概念

領域專家 、通用語言 、領域模型、 戰略建模、 戰術建模。

領域專家: 領域專家，有時也稱爲主題專家，是很是重要的資源。他們對軟件應用領域的瞭解程度對軟件的成敗有直接影響。

通用語言：領域專家與軟件工程師之間溝通的語言 如： 用戶這個名詞， 在電商系統時能夠是買家賣家管理員這些角色在特定的上下文中用戶指的概念是不一樣的；還有訂單號有時是指自有系統的訂單號，有時是指天貓的訂單號，有時是指WMS中的訂單號，雖然都是訂單號但在特定上下文中指代的是不一樣事物概念，而這裏如何區分這些訂單號就須要加上上下文也就是前文中的範圍；如自有系統中的訂單咱們稱其爲系統訂單，天貓訂單咱們稱其爲天貓訂單；而這裏的範圍就是領域，領域可大可小，視其耦合緊密程度而定，而正是這些領域的劃分是領域驅動中最困難的事物。

領域模型：描述某一事物或範圍的一種模型或結構，能夠是圖文也但是UML或代碼，一般對於軟件開發工程師是代碼 也就是描述某一事物的一組對象或服務，因此領域驅動相對於數據庫驅動設計更加面向對象，編寫也更困難一些，但其帶來的好處也是顯而易見的後期代碼愈來愈多某件事物的某個動做與行爲不會散佈在各處，他們有本身專屬的領域位置，項目越大效果越佳。

戰略建模：是指領域對象與服務的劃分與領域之間上下文的映射，是範圍之間如何聯繫與劃分的指導。

戰術建模：是將領域模型經過代碼實現的的一種模式與方法，在後面的文章中會仔細講這一塊。

DDD應用

瞭解與熟悉領域的邊界與合理劃分領域的職責，各司其職，前期領域知識的瞭解與領域的劃分要和領域專家充分的交流溝通，技術手段經過進程或模塊或類將不一樣的領域隔離開來。

歡迎你們評論！

參考資料

Domain-Driven Design