最近幾年，微服務的設計思想，架構方案非常流行，能夠很大程度上保證我們的高性能和高可用，可是微服務設計過程中往往會面臨邊界如何劃定的問題 ，這個時候就需要一種理論指導，這時候來自2004年 埃裏克・埃文斯（Eric Evans）的 領域驅動設計 理論能夠幫助我們更好的進行拆和分，也是微服務架構實踐中非常核心的一部分。
本着深入理解的態度，本文章要作爲一個專欄來進行編寫，作爲2020年開篇的文章，我覺得DDD是我非常感興趣設計思想，希望能夠幫助大家，更好的理解DDD，並在項目中用好DDD。
什麼是領域驅動設計
我們援引wiki上的英文釋義： Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.
DDD是一種通過把設計實現與不斷修正發展的模型緊密關聯起來，來應對複雜需求的一種軟件開發思路。
領域驅動設計的前提是：
- 把項目的主要重點放在覈心領域（core domain）和領域邏輯
- 把複雜的設計放在限界上下文（bounded context）的模型上
- 發起一個技術團隊和領域專家合作的模式，以迭代的方式，解決特定領域的問題
如果覺得應對複雜需求的一種軟件開發思路這句話比較難理解，我們可以來簡單看一下架構的演進。
架構模式的演進
架構是在不斷演進的，一般情況下會經歷到從單體模式 、集中式到分佈式微服務架構三個階段的演進。隨着互聯網公司的發展，分佈式技術的越來越成熟，我們已經進入到了微服務架構的時代。
一般傳統的開發都是單體架構 ： 採用面向過程的設計方法，系統包括客戶端 UI 層和數據庫兩層，採用 C/S 架構模式，整個系統圍繞數據庫驅動設計和開發，並且總是從設計數據庫和字段開始。
轉向微服務設計架構： 隨着微服務架構理念的提出，包括一些開源架構對分佈式技術的支持。微服務的這種架構風格，迅速受到了企業和技術人員的推崇，微服務架構可以很好地實現應用之間的解耦，解決由於單體應用導致的擴展性和彈性伸縮能力不足的問題。 配合一些比較流行的虛擬化技術，能夠實現妙級別的鏡像拉起，極大地增強了應用的的彈性伸縮能力。
爲什麼需要DDD
DDD 是一種處理高度複雜領域的設計思想，它試圖分離技術實現的複雜性，並圍繞業務概念構建領域模型來控制業務的複雜性，以解決軟件難以理解，難以演進的問題。
DDD 不是架構，而是一種架構設計方法論，它通過邊界劃分將複雜業務領域簡單化，幫我們設計出清晰的領域和應用邊界，可以很容易地實現架構演進。
DDD核心設計方法是什麼
戰略設計：
說到戰略設計，我們要站在一個比較高的視角來看待這個問題，戰略設計要解決的就是某個領域的問題，所以戰略設計時，我們要構建好領域模型，保證我們的大方向是不會錯的
戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作爲微服務設計的參考邊界。
戰術設計 :
戰術設計則是要求我們從業務模型轉向微服務落地 我們會將領域模型中的領域對象與代碼模型中的代碼對象建立映射關係，將業務架構和系統架構進行綁定。當我們去響應業務變化調整業務架構和領域模型時，系統架構也會同時發生調整，並同步建立新的映射關係。 也有演進式架構的含義在裏面。
說到這裏，大家可能對DDD有了一個粗略的，大體的認識，我們可以理解到，DDD能夠幫助我們更好的在微服務的架構中進行合理的拆分，由於DDD要求我們建立標準的業務領域模型，所以DDD也能夠很好地幫助我們設計企業的中臺,DDD是一把利器，幫助我們解決架構中遇到的問題和挑戰。
