DDD為什麼能火起來？
我們先不討論DDD的定義， 先梳理一下DDD火起來的背景， 根據我學習的套路， 永遠是為什麼為先，再是解決什麼問題，是什麼東西， 最後如何使用。我們都知道這些年隨著裝置以及技術的發展，軟體架構發生了很多變化，從最初的單機(BS/CS)架構到後面的集中式架構，再到如今的微服務架構， 現在基本可以說是微服務架構盛行的時代， DDD早在2004年就由埃裡克·埃文斯提出， 但一直處於一個不慍不火的狀態，直到Martin Fowler的《Microservices》引起大家注意， 也就是微服務盛行之後(這兒需要說明的是，微服務最早的提出者不是Martin Fowler，而是Fred George)， DDD再次回到人們視野中間，為什麼呢 ？
我們先看一下三種技術架構的演進以及主要區別：
第一階段是單機架構，特徵是整個開發圍繞著資料庫進行設計和開發。
第二個階段是三層式的集中式架構，採用物件導向的設計方法，業務邏輯分業務層、邏輯層、資料訪問層，這種架構很容易某一層或者幾層變得臃腫，擴充套件性較差， 另外摩爾定律失效， 單臺機器效能有限。
第三層階段是微服務架構，在集中式架構中， 系統分析、設計和開發往往是獨立進行的，而且各個階段負責人可能不一樣，那麼就涉及到交流資訊丟失的問題， 另外專案從分析到開發經歷的流程很長，很容易最終開發設計與需求實現的不一樣，微服務主要就是解決第二階段的這些痛點，實現應用之間的解耦，解決單體應用擴充套件性的問題。
微服務存在的問題
進入微服務之後 ， 解決了集中式架構的單體應用很多問題， 但是新的問題應運而生 ， 微服務的粒度應該多大 ？ 微服務如何設計呢？ 微服務如何拆分 ？ 微服務邊界在哪裡 ？
很長時間人們都沒有解決這一問題，就連Martin Fowler在提出微服務架構的時候也沒有告訴我們這該如何拆分微服務。
甚至在很長的時間裡人們對微服務拆分產生了一些誤解， 有人認為："微服務很簡單，就是將之前的單體應用拆分成多個部署包， 或者將原來的單體應用架構替換為一套支援微服務的技術架構，就算是微服務了。" 還有人認為微服務應該拆分得越小越好。
鑑於上述情形， 很多專案因為前期拆分過度， 導致複雜度過高， 導致後期難以運維甚至難以上線。
可以得出一個結論：微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什麼地方。換句話說，確定了業務邊界和應用邊界，這個困境也就迎刃而解了。
而DDD就是解決了這個確定業務邊界的問題，可見DDD並不是一種技術架構，而是一種劃分業務領域範圍的方法論。DDD的興起是由於很多熟悉領域驅動建模(DDD)的工程師在進行微服務設計時， 發現用DDD的思路進行業務梳理可以很好規劃服務邊界， 可以很好實現微服務內部和外部的"高內聚、低耦合"。於是越來越多的人將DDD作為業務劃分的指導思想。
那麼，什麼是DDD呢？
DDD概述
通過上文的學習就可以知道DDD是一種拆解業務、劃分業務、確定業務邊界的方法， 是一種高度複雜的領域設計思想，將我們的問題拆分成一個個的域， 試圖分離技術實現的複雜性，主要解決的是軟體難以理解難以演進的問題，DDD不是一種架構， 而是一種架構方法論， 目的就是將複雜問題領域簡單化， 幫助我們設計出清晰的領域和邊界， 可以很好的實現技術架構的演進。DDD包括兩部分，戰略設計部分和戰術設計部分
戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。
戰術設計則從技術視角出發，側重於領域模型的技術實現，完成軟體開發和落地，包括：聚合根、實體、值物件、領域服務、應用服務和資源庫等程式碼邏輯的設計和實現。
DDD戰略設計會建立領域模型， 這四個字放一起會讓人覺得很高深， 其實是紙老虎， 通俗來說就是模擬某個領域的的一種模型， 這個模型比較抽象， 但便於人們交流， 舉個例子：公園有一棵桃樹， 如果我們想好好研究桃樹該怎麼研究 ？
桃子好吃嗎？ 貴不貴？ 品種？ 怎麼種植？ 種在什麼地方 ？ 做成桃木劍？ 桃子樹葉藥用價值？
你看， 這樣研究每一個問題都很有道理， 但是又很混亂，再回憶一下初中生物書上是這麼研究的？
先將植物根據大家的理解分成多個器官組成， 像桃子、桃葉、桃花等等， 然後將每一個器官再根據功能細分成組織， 再根據這個組織中各個細胞的形態等作用分成不同的細胞， 你看看這是不是一種很有條理的分析方法。
DDD也是如此， 當我們面對桃樹這種複雜的業務的時候，先根據固有的認識分成多個器官(領域)，然後再在每一個領域中根據某些維度(這兒是功能)分為多個組織(聚合)， 而每一個組織中由很多細胞(實體)組成，這就是一種戰略， 有哪些好處呢 ？ 可以確保我們討論的邊界， 也就是討論的東西是一個領域一個維度的， 對於桃樹來說， 桃子 、桃花、桃葉、樹幹都是不同的領域， 劃分不同領域的就是邊界， 我們這兒叫領域邊界， 當我們確定好這些領域之後， 就可以確保我們討論的是同一個領域部分的東西，這樣的好處就是我們可以規定好一些概念， 或者說術語， 以後大家討論的時候就儘可能少的資訊丟失。
DDD戰略設計會建立領域模型 ， 領域模型用來指導微服務的設計和拆分， DDD第一步要做的就是來一個頭腦風暴， 可以理解成一起討論對業務的理解 ， 主要目的就是儘可能前面不遺漏的分解我們的業務領域， 就好比剛剛的桃樹， 最先要做的就是儘可能多的分析， 確保每一個領域都可以被關注到， 在實踐中 ，往往會採用用例分析、場景分析和使用者旅程分析， 這是一個發散的過程，頭腦風暴階段會產生很多實體、命令、事件等領域物件， 我們從不同的維度對進行聚類形成聚合、限界上下文等邊界，建立領域模型， 這是一個收斂的過程。
具體來說， 我們可以通過三步來確定領域模型和微服務邊界。
第一步：在事件風暴中梳理業務過程中的使用者操作、事件以及外部依賴關係等，根據這些要素梳理出領域實體等領域物件。
第二步：根據領域實體之間的業務關聯性，將業務緊密相關的實體進行組合形成聚合，同時確定聚合中的聚合根、值物件和實體。在這個圖裡，聚合之間的邊界是第一層邊界，它們在同一個微服務例項中執行，這個邊界是邏輯邊界，所以用虛線表示。
第三步：根據業務及語義邊界等因素，將一個或者多個聚合劃定在一個限界上下文內，形成領域模型。在這個圖裡，限界上下文之間的邊界是第二層邊界，這一層邊界可能就是未來微服務的邊界，不同限界上下文內的領域邏輯被隔離在不同的微服務例項中執行，物理上相互隔離，所以是物理邊界，邊界之間用實線來表示。
上面除了領域、聚合、實體外還出現了聚合根、值物件等詞語， 除此之外還有統一建模語言、子域、核心域、通用域、支撐域等， 其實都是紙老虎， 前面說過了為了方便對於某個領域的討論往往會形成一些概念，這些概念會有一些名詞概括， 上面的名詞就是這麼來的， 這就叫統一建模語言 ， 哈哈哈 ，好了，不扯淡, 我後面的文章會解釋下這些詞語的意思， 這兒主要討論DDD解決什麼了問題。
梳理一下DDD與微服務的關係， DDD 是一種架構設計方法，微服務是一種架構風格，兩者從本質上都是為了追求高響應力，而從業務視角去分離應用系統建設複雜度的手段。兩者都強調從業務出發，其核心要義是強調根據業務發展，合理劃分領域邊界，持續調整現有架構，優化現有程式碼，以保持架構
和程式碼的生命力，也就是我們常說的演進式架構。DDD 主要關注：從業務領域視角劃分領域邊界，構建通用語言進行高效溝通，通過業務抽象，建立領域模型，維持業務和程式碼的邏輯一致性。微服務主要關
注：執行時的程式間通訊、容錯和故障隔離，實現去中心化資料管理和去中心化服務治理，關注微服務的獨立開發、測試、構建和部署。
總結
這篇文章主要研討了DDD火起來的原因， 解決了什麼業界難題， 知道DDD主要思路 ， 以及DDD大概的實現步驟等 。
留個小問題： 單體應用適合DDD嗎？