一文揭秘DDD到底解決了什麼問題

　　DDD作為架構設計思想幫助微服務控制規模複雜度，那它是怎麼做到的呢？

　　 一、架構設計是為了解決系統複雜度

　　談到架構，相信每個技術人員都是耳熟能詳，但如果深入探討一下，“為何要做架構設計？”或者“架構設計目的是什麼？”類似的問題，大部分人可能從來沒有思考過，或者即使有思考，也沒有太明確可信的答案。

　　1.1 架構設計的誤區

　　1.1.1 每個系統都要做架構設計/公司流程要求有架構設計

　　知其然更要知其所以然，不能僅僅因為其他公司都在做架構設計而盲目跟從，而應該深入理解架構設計的目的和必要性，根據實際需求進行合理的設計。如果架構師或設計師只是為了找點事做而進行架構設計，不僅會浪費時間和人力，還會拖慢整體開發進度。此外，其他公司的架構設計並不一定適用於當前專案，如果強行引入，很可能會導致架構水土不服、執行不流暢等問題，最終需要不斷重構或者推倒重來。因此，架構師或設計師應該深刻理解為何要進行架構設計，避免生搬硬套，針對具體需求進行合理的設計，才能保證專案的順利進行。

　　1.1.2 架構設計是為了追求高效能、高可用、可擴充套件性等單一目標

　　持有這類觀點的人看似具備一定架構經驗或基礎，但實際上他們無論面對什麼系統或業務，都會不顧一切地追求這些目標，導致架構設計變得複雜、專案實施時間拖延、團隊內部不和等問題的出現。這些問題使得整個專案進展緩慢，系統穩定性差，出現問題難以解決，甚至加入新功能也需要花費大量時間。這些情況不是危言聳聽，而是廣泛出現的現象。因此，架構師或設計師必須深入瞭解系統和業務需求，根據實際需要合理設計，不可盲目追求“高XX”目標，才能確保專案開發進度和系統的穩定性。

　　1.2 架構設計的真正目的

　　整個軟體技術發展的歷史，其實就是一部與“複雜度”鬥爭的歷史。架構也是為了應對軟體系統複雜度而提出的一個解決方案，其主要目的是為了解決軟體系統複雜度帶來的問題。

　　那到底什麼是複雜度呢？John Ousterhout教授在 A Philosophy of Software Design 書中提到，複雜度就是任何使得軟體難於理解和修改的因素。

　　複雜的系統有一些非常明顯的特徵，John教授將它抽象為變更放大（Change amplification）、認知負荷（Cognitive load）與未知的未知（Unknown unknowns）這3類。

　　變更放大（Change amplification）指得是看似簡單的變更需要在許多不同地方進行程式碼修改。系統開發者之前沒有及時重構程式碼，提取公共邏輯，而是省時間Ctrl-C，Ctrl-V式程式碼開發（這樣做不會影響已有的穩定模組，不需要做比較多的迴歸測試，上線風險小）。當需求變化時，需要改動多處程式碼。

　　認知負荷（Cognitive load）是指系統的學習與理解成本高，開發人員的研發效率大大降低。

　　未知的未知（Unknown unknowns）是指不知道修改哪些程式碼才能使系統功能正確的執行，也不知道這行程式碼的改動是否會引發線上問題。這一項是複雜性中最糟糕的一個表現形式。

　　1.3 系統複雜度的六個來源及通用解法

　　本段參考 參考5

　　1.高效能 2.高可用 3.可擴充套件性 4.低成本 5.安全 6.規模

　　1.3.1 高效能

　　軟體系統中高效能帶來的複雜度主要體現在兩方面：

　　1.一方面是單臺計算機內部為了高效能帶來的複雜度；

　　2.另一方面是多臺計算機叢集為了高效能帶來的複雜度。

　　1.3.1.1 單機複雜度

　　計算機內部複雜度最關鍵的地方就是作業系統，計算機效能的發展本質上是由硬體發展驅動的，尤其是 CPU 的效能發展。而將硬體效能充分發揮出來的關鍵就是作業系統，所以作業系統本身也是隨硬體的發展而發展的，作業系統是軟體系統的執行環境，作業系統的複雜度直接決定了軟體系統的複雜度。

　　作業系統和效能最相關的就是程式和執行緒。

　　程式：用程式來對應一個作業系統執行的任務，每個任務都有自己獨立的記憶體空間，程式間互不相關，由作業系統來進行排程。

　　多程式：為了達到多程式並行執行的目的，採取了分時的方式，即把 CPU 的時間分成很多片段，每個片段只能執行某個程式中的指令。

　　程式間通訊：為了解決程式在執行時相互通訊的問題，人們設計了各種程式間通訊，包括管道、訊息佇列、訊號量、共享儲存等。

　　多執行緒：多程式讓多工能夠並行處理任務，但本身還有缺點，單個程式內部只能序列處理，而實際上很多程式內部的子任務並不要求是嚴格按照時間順序來執行的，也需要並行處理。為了解決這個問題發明了執行緒，執行緒是程式內部的子任務，但這些子任務都共享同一份程式資料。為了保證資料的正確性，又發明了互斥鎖機制。有了多執行緒後，作業系統排程的最小單位就變成了執行緒，而程式變成了作業系統分配資源的最小單位。

　　作業系統發展到現在，如果要完成一個高效能的軟體系統，需要考慮如多程式、多執行緒、程式間通訊、多執行緒併發等技術點，而且這些技術並不是最新的就是最好的，也不是非此即彼的選擇。

　　在做架構設計的時候，需要花費很大的精力來結合業務進行分析、判斷、選擇、組合，這個過程同樣很複雜。例如，下面的系統都實現了高效能，但是內部實現差異很大：

　　Nginx 可以用多程式也可以用多執行緒

　　JBoss 採用的是多執行緒

　　Redis 採用的是單程式

　　Memcache 採用的是多執行緒

　　1.3.1.2 叢集複雜度

　　讓多臺機器配合起來達到高效能的目的，是一個複雜的任務，常見的方式有：

　　任務可以指完整的業務處理，也可以指某個具體的任務。

　　1.任務分配：每臺機器都可以處理完整的業務任務，不同的任務分配到不同的機器上執行。

　　2.任務分解：業務越來越複雜，單臺機器處理的效能會越來越低。為了能夠繼續提升效能，採用任務分解。

　　1.3.1.2.1任務分配　　

　　增加一個任務分配器，可以是硬體（F5、交換機）、軟體（LVS）、負載均衡軟體（Nginx、HAProxy）、自己開發的系統。

　　任務分配器與業務伺服器之間的連線和互動。

　　任務分配器增加分配演算法（輪詢、權重、負載）。

　　業務量繼續提升，需要增加任務分配器的數量。　　

　　任務分配器增加為多臺，這樣需要將不同的使用者請求分配到不同的任務分配器上（DNS輪詢、智慧DNS、CDN、GSLB全域性負載均衡）。

　　任務分配器和業務伺服器之間從一對多變成多對多的網狀結構。

　　業務伺服器繼續擴增，狀態管理和故障處理複雜度更大。

　　1.3.1.2.2 任務分解

　　微服務架構就採用了這種思路，透過任務分配的方式，能夠突破單臺機器處理效能的瓶頸，透過增加更多的機器來滿足業務的效能需求，但如果業務本身也越來越複雜，單純只透過任務分配的方式來擴充套件效能，收益會越來越低。　　

　　透過這種任務分解的方式，能夠把原來大一統但複雜的業務系統，拆分成小而簡單但需要多個系統配合的業務系統。從業務的角度來看，任務分解既不會減少功能，也不會減少程式碼量（事實上程式碼量可能還會增加，因為從程式碼內部呼叫改為透過伺服器之間的介面呼叫），任務分解能夠提升效能的主要原因是：

　　1.簡單的系統更容易做到高效能：系統的功能越簡單，影響效能的點就越少，就更加容易進行有針對性的最佳化。

　　2.可以針對單個任務進行擴充套件：當各個邏輯任務分解到獨立的子系統後，整個系統的效能瓶頸更加容易發現，而且發現後只需要針對有瓶頸的子系統進行效能最佳化或者提升，不需要改動整個系統，風險會小很多。

　　最終決定業務處理效能的還是業務邏輯本身，業務邏輯本身沒有發生大的變化下，理論上的效能是有一個上限的，系統拆分能夠讓效能逼近這個極限，但無法突破這個極限。

　　1.3.2 高可用

　　系統無中斷地執行其功能的能力，代表系統的可用性程度，是進行系統設計時的準則之一。

　　本質上都是透過“冗餘”來實現高可用。高可用的“冗餘”解決方案，單純從形式上來看，和高效能是一樣的，都是透過增加更多機器來達到目的，但其實本質上是有根本區別的：高效能增加機器目的在於“擴充套件”處理效能；高可用增加機器目的在於“冗餘”處理單元。

　　透過冗餘增強了可用性，但同時也帶來了複雜性。

　　1.3.2.1 計算高可用

　　計算的特點是無論從哪臺機器上進行計算，同樣的演算法和輸入資料，產出的結果都是一樣的，所以將計算從一臺機器遷移到另一臺對業務沒有影響。　　

　　需要增加一個任務分配器

　　任務分配器和真正的業務伺服器之間有連線和互動

　　任務分配器需要增加分配演算法（主備【冷備、溫備、熱備】、主主、多主多倍【2主2備、4主0備】）

　　1.3.2.2 儲存高可用

　　對於需要儲存資料的系統而言，整個系統的高可用設計的難點和關鍵點在於“儲存高可用”。儲存和計算的本質區別在於將資料從一臺機器搬移到另一臺機器時需要透過線路進行傳輸，而線路傳輸是存在延遲的，速度在毫秒級別，距離越遠，延遲越高。加之各種異常情況（如傳輸中斷、丟包、擁塞），會導致延遲更高。對於高可用系統來說，在某個時間點通訊中斷就意味著整個系統的資料不一致。按照“資料 + 邏輯 = 業務”的公式，資料不一致將導致最終業務表現不同。如果不做冗餘備份，系統的整體高可用性無法保證。因此，儲存高可用的難點不在於如何備份資料，而在於如何減少或規避資料不一致對業務造成的影響。

　　分散式領域內著名的 CAP 定理從理論上證實了儲存高可用的複雜度。儲存高可用不可能同時滿足“一致性、可用性、分割槽容忍性”，最多隻能滿足其中兩個。因此，在進行架構設計時需要結合業務進行取捨。

　　1.3.3 可擴充套件性

　　可擴充套件性指系統為了應對將來需求變化而提供的一種擴充套件能力，當有新的需求出現時，系統不需要或者僅需要少量修改就可以支援，無須整個系統重構或者重建。

　　在軟體開發領域，物件導向思想的提出，就是為了解決可擴充套件性帶來的問題；設計模式更是將可擴充套件性做到了極致。

　　設計具備良好可擴充套件性的系統，有兩個基本條件：

　　正確預測變化

　　完美封裝變化

　　1.3.3.1 預測變化

　　“唯一不變的是變化”，按照這個標準衡量，架構師每個設計方案都要考慮可擴充套件性。預測變化的複雜性在於：

　　不能每個設計點都考慮可擴充套件性

　　不能完全不考慮擴充套件性

　　所有的預測都存在出錯的可能性

　　如何把握預測的程度和提升預測結果的準確性，是一件很複雜的事情，而且沒有通用的標準，更多是靠經驗、直覺。

　　1.3.3.2 應對變化

　　預測變化是一回事，採取什麼方案來應對變化，又是另外一個複雜的事情。即使預測很準確，如果方案不合適，則系統擴充套件一樣很麻煩。

　　微服務架構中的各層進行封裝和隔離也是一種應對變化的解決方式。

　　1.3.3.2.1 變化層VS穩定層

　　第一種應對變化的常見方案是將“變化”封裝在一個“變化層”，將不變的部分封裝在一個獨立的“穩定層”。

　　無論是變化層依賴穩定層，還是穩定層依賴變化層都是可以的，需要根據具體業務情況來設計。

　　無論採取哪種形式，透過剝離變化層和穩定層的方式應對變化，都會帶來兩個主要的複雜性相關的問題。

　　1.系統需要拆分出變化層和穩定層（如何拆分）

　　2.需要設計變化層和穩定層之間的介面（穩定層介面越穩定越好，變化層介面從差異中找到共同點）

　　1.3.3.2.2 抽象層VS實現層

　　第二種常見的應對變化的方案是提煉出一個“抽象層”和一個“實現層”。

　　抽象層是穩定的，實現層可以根據具體業務需要定製開發，當加入新的功能時，只需要增加新的實現，無須修改抽象層。這種方案典型的實踐就是策略模式。

　　1.3.4 低成本

　　在設計高效能、高可用的架構方案時，如果涉及到數百、數千甚至數萬臺伺服器，成本就會成為一個非常重要的考慮點。為了控制成本，需要減少伺服器的數量，這與增加更多伺服器來提升效能和可用性的通用做法相沖突。因此，低成本往往不是架構設計的首要目標，而是一個附加約束。為了解決這個問題，需要先設定一個成本目標，然後根據高效能和高可用的要求設計方案，並評估是否能夠滿足成本目標。如果不能，就需要重新設計架構；如果無論如何都無法設計出滿足成本要求的方案，那隻能找老闆調整成本目標了。低成本給架構設計帶來的主要複雜度體現在，往往只有"創新"才能達到低成本目標。"創新"的含義是開創一個全新的技術領域，或者引入新技術來解決問題。如果沒有找到能夠解決自己問題的新技術，那麼就需要自己創造新技術了。例如，NoSQL（如Memcache、Redis等）是為了解決關係型資料庫無法應對高併發訪問帶來的訪問壓力；全文搜尋引擎（如Sphinx、Elasticsearch、Solr）是為了解決關係型資料庫like搜尋的低效問題；Hadoop則是為了解決傳統檔案系統無法應對海量資料儲存和計算的問題。創造新技術的主要複雜度在於需要創造全新的理念和技術，並且新技術需要與舊技術相比有質的飛躍。

　　1.3.5 安全

　　從技術的角度來講，安全可以分為兩類：

　　一類是功能上的安全，

　　一類是架構上的安全。

　　1.3.5.1 功能安全

　　常見的 XSS 攻擊、CSRF 攻擊、SQL 注入、Windows 漏洞、密碼破解等，本質上是因為系統實現有漏洞，駭客有了可乘之機，功能安全其實就是“防小偷”。

　　從實現的角度來看，功能安全更多地是和具體的編碼相關，與架構關係不大。開發框架會內嵌常見的安全功能，但是開發框架本身也可能存在安全漏洞和風險。

　　所以功能安全是一個逐步完善的過程，而且往往都是在問題出現後才能有針對性的提出解決方案，我們永遠無法預測系統下一個漏洞在哪裡，也不敢說自己的系統肯定沒有任何問題。

　　換句話講，功能安全其實也是一個“攻”與“防”的矛盾，只能在這種攻防大戰中逐步完善，不可能在系統架構設計的時候一勞永逸地解決。

　　1.3.5.2 架構安全

　　如果說功能安全是“防小偷”，那麼架構安全就是“防強盜”。

　　架構設計時需要特別關注架構安全，尤其是網際網路時代，理論上來說系統部署在網際網路上時，全球任何地方都可以發起攻擊。

　　傳統的架構安全主要依靠防火牆，防火牆最基本的功能就是隔離網路，透過將網路劃分成不同的區域，制定出不同區域之間的訪問控制策略來控制不同信任程度區域間傳送的資料流。

　　防火牆的功能雖然強大，但效能一般，所以在傳統的銀行和企業應用領域應用較多。但在網際網路領域，防火牆的應用場景並不多。

　　網際網路系統的架構安全目前並沒有太好的設計手段來實現，更多地是依靠運營商或者雲服務商強大的頻寬和流量清洗的能力，較少自己來設計和實現。

　　1.3.6 規模

　　規模帶來複雜度的主要原因就是“量變引起質變”，當數量超過一定的閾值後，複雜度會發生質的變化。常見的規模帶來的複雜度有：

　　1.功能越來越多，系統複雜度指數級上升

　　2.資料越來越多，系統複雜度發生質變

　　1.3.6.1 功能越來越多，系統複雜度指數級上升

　　例如，某個系統開始只有 3 大功能，後來不斷增加到 8 大功能，雖然還是同一個系統，但複雜度已經相差很大了，具體相差多大呢？我以一個簡單的抽象模型來計算一下，假設系統間的功能都是兩兩相關的，系統的複雜度 = 功能數量 + 功能之間的連線數量，透過計算我們可以看出：3個功能的系統複雜度為3+3=6

　　8個功能的系統複雜度為8+（7+0）*8/2=36 可以看出，具備8個功能的系統的複雜度不是比具備 3 個功能的系統的複雜度多5，而是多了30，基本是指數級增長的，主要原因在於隨著系統功能數量增多，功能之間的連線呈指數級增長。下圖形象地展示了功能數量的增多帶來了複雜度。　　

　　1.3.6.2 資料越來越多，系統複雜度發生質變

　　隨著資料量的不斷增長，傳統的資料處理和管理方式已經無法適應，因此“大資料”這一概念應運而生。大資料的誕生主要是為了解決資料規模變得越來越大時，傳統的資料收集、儲存、分析等方式無法勝任的問題。Google的三篇技術論文，即Google File System、Google Bigtable和Google MapReduce則分別開創了大資料檔案儲存、列式資料儲存和大資料運算的技術領域。即便資料規模沒有達到大資料的水平，資料增長仍然可能會給系統帶來複雜性。例如，在使用關聯式資料庫儲存資料時，當單表資料達到一定規模時，就會導致新增索引、修改表結構等操作變得很慢，可能需要幾個小時，這就會對業務造成不良影響。因此，必須考慮將單表拆分為多表來解決這個問題，但這個過程也會引入更多的複雜性。

　　1.4 簡單的複雜度分析案例

　　我們來分析一個簡單的案例，一起來看看如何將“架構設計的真正目的是為了解決軟體系統複雜度帶來的問題”這個指導思想應用到實踐中。

　　當我們設計一個大學的學生管理系統時，我們需要考慮該系統的複雜度以及如何解決這些複雜度帶來的問題。首先，我們可以將該系統的複雜度分為以下幾個方面：

　　效能 該系統的訪問頻率並不高，因此效能並不是一個很大的問題。我們可以使用MySQL作為儲存，Nginx作為Web伺服器，無需考慮快取。

　　可擴充套件性 該系統的功能比較穩定，可擴充套件的空間並不大，因此可擴充套件性方面也不是一個很大的問題。

　　高可用 資料丟失是不可接受的，故該系統的高可用性方面需要考慮多種異常情況，如機器故障、機房故障等。為此，我們需要設計MySQL同機房主備方案和MySQL跨機房同步方案。

　　安全性 該系統儲存的資訊涉及到學生的隱私，因此需要考慮安全性。我們可以使用Nginx提供的ACL控制、使用者賬號密碼管理和資料庫訪問許可權控制來保證系統的安全性。

　　成本 由於該系統比較簡單，基本上幾臺伺服器就可以搞定，因此成本方面並不需要太多關注。

　　規模 同上，規模複雜度無需過度關注。

　　總體來說，我們需要在架構設計中充分考慮系統的複雜度，同時根據不同問題選擇合適的解決方案，以提高系統的可靠性和安全性。

　　1.5 總結

　　第一章提出了架構的根本目是解決系統複雜度，並簡要說明系統複雜度的六個來源及通用解法，為我們設計架構提供了清晰可執行的操作思路。

　　 二、微服務架構解決了高可用、可擴充套件問題，但效能下降、成本&規模複雜度暴增

　　我們知道，這些年來隨著裝置和新技術的發展，軟體的架構模式發生了很大的變化。軟體架構模式大體來說經歷了從單機、集中式到分散式微服務架構三個階段的演進 。隨著分散式技術的快速興起，我們已經進入到了微服務架構時代。　　

　　2.1 微服務架構的優點

　　與傳統單體應用架構相比，微服務架構有很多優點，具體表現如下：

　　2.1.1 高可用

　　當架構中的某一元件發生故障時，在單一程式的傳統架構下，故障很有可能在程式內擴散，導致整個應用不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可透過重試、平穩退化等機制實現應用層面的容錯。

　　2.1.4 可擴充套件

　　單個服務應用也可以實現橫向擴充套件，這種擴充套件可以透過將整個應用完整的複製到不同的節點中實現。當應用的不同元件在擴充套件需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴充套件。

　　2.2 微服務的缺點

　　2.2.1 複雜度高

　　與單體式架構相比，微服務會導致複雜性上升，因為多個團隊會在更多地方建立更多服務。若管理不當，則會導致開發速度和效率降低。

　　2.2.2 基礎設施成本呈指數級增長

　　每個新的微服務都有自己的成本，例如測試工具、託管基礎架構和監控工具等方面。

　　2.2.3 效能下降

　　微服務之間透過REST、RPC等形式進行互動，通訊的時延會受到較大的影響。

　　 三、DDD幫助微服務控制規模複雜度

　　3.1 控制成本&規模複雜度需要明晰微服務的邊界

　　由1.3.6.1 所述，隨著微服務數量上升，規模複雜度呈指數級上升，那麼我們理應控制微服務的數量，這就帶來了爭論和疑惑：微服務的粒度應該多大呀？微服務到底應該如何拆分和設計呢？

　　長期以來，微服務架構缺乏一套系統的理論和方法來指導其拆分，這導致了一些人對微服務架構的理解出現了一些曲解。有人簡單地認為微服務只是將原來的單體應用程式拆分為多個部署包或更換為支援微服務架構的技術框架，便可成為微服務。還有人認為，微服務越小越好。

　　然而，在過去的幾年中，一些專案由於在前期過度拆分微服務，導致專案複雜度過高，無法進行上線和運維的情況已經出現。綜合來看，我認為微服務拆分困境的根本原因在於不清楚業務或微服務的邊界在哪裡。換句話說，只有確定了業務邊界和應用邊界，這個困境才能迎刃而解。

　　3.2 DDD能夠幫我們設計出清晰的領域和應用邊界

　　DDD 包括戰略設計和戰術設計兩部分。戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，這些限界上下文可以作為微服務設計的參考邊界。而戰術設計則從技術視角出發，著重於領域模型的技術實現，包括聚合根、實體、值物件、領域服務、應用服務和資源庫等程式碼邏輯的設計和實現。

　　在戰略設計過程中，領域模型的建立是重中之重。為此，DDD 提出了事件風暴這一建立領域模型的方法。事件風暴是一個從發散到收斂的過程，通常採用用例分析、場景分析和使用者旅程分析，全面分解業務領域，梳理領域物件之間的關係，這是一個發散的過程。在事件風暴過程中，會產生很多實體、命令、事件等領域物件，我們將這些領域物件從不同的維度進行聚類，形成如聚合、限界上下文等邊界，建立領域模型，這就是一個收斂的過程。

　　因此，DDD 可以幫助軟體工程師建立清晰的領域模型，劃分業務和應用邊界，以指導微服務的設計和拆分。事件風暴是建立領域模型的主要方法，透過其發散的過程和聚合的過程，建立起合理的領域模型，從而實現高效的軟體開發和落地。　　

　　我們可以用三步來劃定領域模型和微服務的邊界。

　　在領域驅動設計的戰略設計中，我們採用事件風暴方法梳理業務過程中的使用者操作、事件以及外部依賴關係等，從而梳理出領域實體等領域物件。

　　然後，我們根據領域實體之間的業務關聯性，形成聚合，並確定聚合中的聚合根、值物件和實體。

　　接著，根據業務及語義邊界等因素，將一個或多個聚合劃定在一個限界上下文內，形成領域模型。這個過程中，我們建立了領域模型，劃定了業務領域的邊界，建立了通用語言和限界上下文，確定了領域模型中各個領域物件的關係。這些限界上下文可以作為微服務設計的參考邊界，從而確定了應用端的微服務邊界。

　　在從業務模型向微服務落地的過程中，即從戰略設計向戰術設計的實施過程中，我們會將領域模型中的領域物件與程式碼模型中的程式碼物件建立對映關係，將業務架構和系統架構進行繫結。當調整業務架構和領域模型以響應業務變化時，系統架構也會同時發生調整，並同步建立新的對映關係。這種方式可以幫助我們實現高效的軟體開發和落地，從而更好地應對業務需求變化。

　　因此，透過領域驅動設計的戰略設計和戰術設計，我們可以清晰地劃定領域邊界，建立領域模型，幫助我們實現微服務的設計和拆分，同時也能夠有效地響應業務變化，提高軟體開發和落地的效率。

　　3.3 微服務與DDD的異同

　　DDD 是一種面向複雜業務領域的設計方法論，而微服務是一種面向分散式系統的架構風格。它們的共同目標都是透過將系統分解為更小，更易於管理的元件來提高系統的可維護性和可擴充套件性。

　　在 DDD 中，我們關注的是業務領域的劃分和領域模型的設計，以便更好地理解業務需求，並將其轉化為可執行的程式碼。

　　在微服務中，我們主要關注的是執行時的通訊，容錯和故障隔離，以及服務治理等問題，以確保各個微服務可以獨立開發、測試、構建和部署。

　　透過結合 DDD 和微服務，我們可以更好地實現高效的業務邏輯，同時也可以充分利用微服務的優點，提高應用程式的可擴充套件性和可維護性。因此，DDD 和微服務是互補的，可以共同用於構建可靠且高效的應用程式。