06 | 領域事件：解耦微服務的關鍵
課程鏈接：https://time.geekbang.org/column/article/155444
在事件風暴中，除了命令和操作等業務行爲，還有領域事件，這種事件發生後通常會導致進一步的業務操作。
領域事件用來白哦是領域中發生的事件。在實現業務解耦的同時，還有助於形成完整的業務閉環。例如，領域事件可以是業務流程的一個步驟，比如投保業務繳費完成後，觸發投保單轉保單的動作；也可能是定時批處理過程發生的事件，比如批處理生成季繳保費通知單，觸發發送繳費郵件通知操作；或者一個事件發生後觸發的後續動作，比如密碼連續輸錯三次，觸發鎖定賬戶的動作。
如何識別領域事件？在做用戶旅程或場景分析時，捕捉業務、需求人員或領域專家口中的關鍵詞：“如果發生...則...”、“當做完...的時候，請通知...”、發生...時，則...“等。這些場景發生某種時間後會觸發進一步操作，那麼這個事件很可能時領域事件。
領域事件驅動設計可以切斷領域模型之間的強依賴關係，事件發佈完成後，發佈方不必關係後續訂閱方事件處理是否成固，這樣可以實現領域模型的解耦，維護獨立性和數據一致性。在領域模型映射到微服務系統架構時，領域事件可以解耦微服務，微服務之間的數據不必要求強一致性，而是基於事件的最終一致性。
有的領域事件發生在微服務內的聚合之間，有的發生在微服務之間，還有兩者皆有的場景，一般來說跨微服務的領域事件處理居多。
1.微服務內的領域事件
當領域事件發生在微服務內的聚合之間，領域事件發生後完成事件實體構建和事件數據持久化，發佈方聚合將事件發佈到事件總線，訂閱方接收事件數據完成後續業務操作。微服務內大部分事件的結成，都發生在同一個進程內，進程自身可以很好的控制事務，因此不一定需要引入消息中間件。但一個事件如果同時更新多個聚合，就要考慮是否引入事件總線。但微服務內的事件總線，會增加開發難度。微服務內應用服務，可以通過跨聚合的服務編排和組合，以服務調用的方式完成跨聚合的訪問，這種方式通常應用於實時性和數據一致性要求高的場景。這個過程會用到分佈式事務，保證發佈方和訂閱方數據同時更新成功。
2.微服務之間的領域事件
跨微服務的領域事件會在不同的限界上下文或領域模型之間實現業務協作，主要爲了實現微服務解耦，減輕微服務之間實時訪問的壓力。這種場景比較多，事件處理機制也更復雜。跨微服務的事件可以推動業務流程或者數據在不同的子域或微服務間直接流轉。跨微服務的事件機制要總體考慮事件構建、發佈和訂閱、事件數據持久化、消息中間件，甚至事件數據持久化時還要考慮引入分佈式事務。
微服務之間的訪問也可以採用應用服務直接調用的方式，實現數據的服務的實施訪問，弊端就是跨微服務的數據同時變更需要引入分佈式事務，這樣會影響系統性能，增加服務之間耦合，還是要避免使用分佈式事務。
領域事件相關案例
保險承保業務。一個保單的生成，經歷了很多子域、業務狀態變更和跨微服務業務數據的傳遞。產生了很多領域事件，促成了保險業務數據、對象在不同微服務和子域之間的流轉和角色轉換。
如何用領域事件驅動設計來驅動承保業務流程：
事件起點：客戶購買保險 - 業務完成保單錄入 - 生成投保單 - 啓動繳費動作。
1.投保微服務生成繳費通知單，發佈第一個事件：將繳費通知單數據發佈到MQ。收款微服務訂閱該MQ，完成繳費操作。繳費通知單已生成，領域事件結束。
2.收款微服務繳費完成後，發佈第二個事件：繳費已完成，將繳費數據發佈到MQ。投保微服務收到該MQ並確認繳費完成，完成投保單轉保單的操作。繳費已完成，領域事件結束。
3.投保微服務在投保單轉保單完成後，發佈第三個事件：保單已生成，將保單數據發佈MQ。保單微服務接受到該MQ，完成保單數據保存操作。保單已生成，領域事件結束。
4.後面還會發生一系列領域事件，併發的將保單數據通過MQ發送到佣金、收付費、和再保等微服務，完成後續所有業務流程。
總之，通過領域事件驅動的異步化機制，可以推動業務流程和數據在各個微服務之間流轉，實現微服務解耦。
領域事件總體架構
領域事件的執行需要一系列組件和技術做支撐。領域事件處理包括：事件構建和發佈、事件數據持久化、事件總線、消息中間件、事件接受和處理等。
1.事件構建與發佈
事件基本屬性至少包括：事件唯一標識、發生時間、事件類型和事件源。事件唯一標識應該是全局唯一的，以便無歧義的在多個限界上下文中傳遞。事件基本屬性記錄事件滋生以及事件發生背景的數據。時間還有業務屬性，用於記錄事件發生時的業務數據，會隨事件傳輸到訂閱方。事件基本屬性和業務屬性一起構成事件實體，事件實體依賴聚合根。領域事件發生後，事件中的業務數據不再修改，因此業務數據可以以序列化值對象的形式保存，這樣在MQ中也比較容易解析和獲取。
事件發佈前要縣構建事件實體並持久化。事件發佈的方式：可以通過應用服務或領域服務發佈到事件總線或者MQ，也可以從事件表中利用定時程序或數據庫日誌捕捉技術獲取增量事件數據，發佈到MQ。
2.事件數據持久化
可用於系統之間的數據隊長，或實現發佈方和訂閱方事件數據的審計。當遇到MQ、訂閱方宕機或網絡中斷，在問題解決後仍可繼續後續業務流轉，保證數據一致性。
持久化方案有兩種：
- 持久化到本地業務數據庫中，利用本地事務保證業務和事件數據的一致性
- 持久化到共享的事件數據庫中。業務數據庫和事件數據庫不是一個，他們的數據持久化操作會跨數據庫，因此需要分佈式事務來保證業務和事件數據的強一致性。
3.事件總線（EventBus）
事件總線是實現微服務內聚合之間領域事件的重要組件，提供事件分發和接收等服務。是進程內模型，會在微服務內聚合之間遍歷訂閱者列表，採取同步或異步的模式傳遞數據。事件分發流程大致如下：
- 如果是微服務內的訂閱者（其他聚合），則直接分發到指定訂閱者；
- 如果是微服務外的訂閱者，將事件數據保存到事件庫並異步發送到消息中間件；
- 如果同時存在微服務內和外訂閱者，則先處理內部訂閱者，再處理外部訂閱者
4.消息中間件
跨微服務的領域事件大多會用到消息中間件，實現跨微服務的事件發佈和訂閱。Kafka，RabbitMQ等
5.事件接收和處理
微服務訂閱方再應用層採用監聽機制，接收MQ中的事件數據，完成持久化後，可以開始進一步的業務處理。
領域事件運行機制案例
承保業務流程的通知繳費通知單事件爲例。發生再投保和收款微服務之間。領域事件是：繳費通知單已生成。下一步業務操作是：繳費。
事件起點：出單員生成投保單，覈保通過後，發起生成繳費通知單的操作。
1.投保微服務應用服務，調用聚合中的領域服務createPaymentNotice和createPaymentNoticeEvent，分別創建繳費通知單、繳費通知單事件。繳費通知單類PaymentNoticeEvent繼承基類DomainEvent。
2.利用倉儲服務持久化繳費通知單相關的業務和事件數據。爲避免分佈式事務，這些數據都持久化到本地投保微服務數據庫中。
3.通過數據庫日誌捕獲技術或定時程序，從數據庫事件表中獲取事件增量數據，發佈到MQ。事件發佈也可以通過應用服務或領域服務完成發佈。
4.收款微服務再應用層從MQ訂閱繳費通知單事件消息主題，監聽並獲取事件數據後，應用服務調用領域層的領域服務將事件數據持久化到本地數據庫。
5.收款微服務調用領域岑的領域服務PayPremium，完成繳費。
6.事件結束。
提示：繳費完成後，後續還會產生很多新的領域事件。
領域事件驅動是很成熟的技術，很多分佈式架構中有大量的使用。是DDD的重要概念，用領域事件驅動業務流轉。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
07 | DDD分層架構：有效降低層與層之間的依賴
課程鏈接：https://time.geekbang.org/column/article/156849
微服務架構模型：整潔架構、CQRS、六邊形架構、DDD分層架構。
DDD分層架構，最早是傳統的四層架構；後來有了優化，實現各層對基礎層的解耦；再後來領域層和應用層之間增加了上下文環境（Context），形成了五層架構（DCI）。
最早的四層架構中，基礎層是被其他層依賴的，位於最核心的位置，但實際上領域層纔是軟件的核心，所以有問題。
後來採用依賴倒置（Dependency inversion principle，DIP）的設計盡心優化，實現各層對基礎層的解耦。
下面是DDD分層架構：
1.用戶接口層：負責向用戶顯示信息和解釋用戶指令，可以是用戶、程序、自動化測試和批處理腳本等。
2.應用層：很薄，理論上不會有業務規則或邏輯，主要面向用例和流程相關的操作。位於領域層之上，因爲領域層包含多個聚合，所以它可以協調多個聚合的服務和領域對象完成服務編排和組合。另外也是微服務之間交互的通道，可以調用其他微服務的應用服務。
在設計和開發時，不要將本該放在領域層的業務邏輯放到應用層實現。因爲龐大的應用層會使領域模型失焦，時間一長微服務就會演化爲傳統的三層架構，會很混亂。
應用服務是在應用層的，負責服務的組合和轉發，負責處理業務用例的執行順序和結果拼裝，以粗粒度的服務通過API網關向前端發佈，還可以進行安全認證、權限校驗、事務控制、發送或訂閱領域事件等。
3.領域層：實現企業核心邏輯，保證業務正確性。主要體現模型的業務能力。
包含聚合根、實體、值對象、領域服務等領域模型中的領域對象。
首先，領域模型的業務邏輯主要是由實體和領域服務來實現的，其中實體會採用充血模型來實現所有與之相關的業務功能。其次，實體和領域模型在實現業務邏輯上不是同級的，當領域中的某些功能，單一實體（或者值對象）不能實現時，領域服務就會出馬，它可以組合聚合內的多個實體（或者值對象），實現複雜的業務邏輯。
4.基礎層：貫穿所有，爲其他各層提供通用的技術和基礎服務，如第三方工具、驅動、消息中間件、網關、文件、緩存以及數據庫。它包含基礎服務，採用依賴倒置設計，實現應用層、領域層與基礎層的解耦，降低外部資源變化對應用的影響。例如傳統架構中，最擔憂的就是換數據庫，因爲可能要重寫大部分代碼。採用依賴倒置的設計後，應用層就可以通過解耦來保持獨立的核心業務邏輯。數據庫變更時，只需要更換數據庫基礎服務就可以了。
DDD分層架構的重要原則：每層只能與位於其下方的層發生耦合。
架構根據解耦的緊密程度可以分成兩種：嚴格分層架構和鬆散分層架構。優化後的DDD分層架構就屬於嚴格分層架構，任何層只能對位於其直接下方的層產生依賴。傳統的DDD分層架構屬於鬆散分層架構，允許某層與任意下方的層發生依賴。推薦選擇嚴格分層架構，領域服務只能被應用服務調用，應用服務只能被用戶接口層調用，服務逐層對外封裝或組合，關係清晰。但是鬆散分層架構中領域服務可以同時被應用層和用戶接口層調用，關係複雜難以管理，甚至容易使核心業務邏輯外泄。
如果領域層中的某個服務發生了重大變更，在嚴格分層架構中，只需要逐層通知上層服務就可以了。
DDD分層架構推動架構演進
1.微服務架構的演進
領域模型中對象的層次從內到外依次是：值對象、實體、聚合、限界上下文。
實體或值對象的簡單變更，一般不會使領域模型和微服務發生大的變化。但聚合的重組或拆分卻可以。因爲聚合內業務功能內聚，能獨立完成特定的業務邏輯。可以以聚合爲基礎單元，完成領域模型和微服務架構的演進。聚合可以作爲一個整體在不同的領域模型之間重組或拆分，或者直接將一個聚合獨立爲微服務。
上圖爲例：①當發現微服務1中的聚合a的功能被高頻訪問，甚至拖垮整個微服務1的性能，可以把聚合a的代碼，獨立爲微服務2，它可以輕鬆應對高性能場景；②發現微服務3的領域模型有了變化，聚合d更適合放到微服務1中。可以將d整體搬遷到微服務1中，如果合計時已經定義好了聚合之間的代碼邊界，這個過程不會太複雜。③經歷模型和架構演進後，微服務1已經從最初包含聚合a、b、c，演進爲包含聚合b、c、d。
怎麼實現聚合代碼快速重組呢？後面實戰再講。
2.微服務內服務的演進
微服務內部，實體的方法被領域服務組合和封裝，領域服務又被應用服務組合和封裝。在逐層組合和封裝時，會出現：
服務設計時，並不一定能完整預測有哪些下層服務會被多少個上層服務組裝，因此領域層通常只提供一些原子服務，比如領域服務 a、b、c。但隨着系統功能增強和外部接入越來越多，應用服務會不斷豐富。有一天你會發現領域服務 b 和 c 同時多次被多個應用服務調用了，執行順序也基本一致。這時你可以考慮將 b 和 c 合併，再將應用服務中 b、c 的功能下沉到領域層，演進爲新的領域服務（b+c）。這樣既減少了服務的數量，也減輕了上層服務組合和編排的複雜度。服務演進的過程是隨着系統發展的。
三層架構如何演進到DDD分層架構？
首先，由於層間鬆耦合，我們可以專注於本層的設計，而不必關心其它層，也不必擔心自己的設計會影響其它層。DDD 成功地降低了層與層之間的依賴。其次，分層架構使得程序結構變得清晰，升級和維護更加容易。我們修改某層代碼時，只要本層的接口參數不變，其它層可以不必修改。即使本層的接口發生變化，也隻影響相鄰的上層，修改工作量小且錯誤可以控制，不會帶來意外的風險。
該怎樣轉向DDD分層架構？
傳統企業應用大多是單體架構，而單體架構則大多是三層架構。三層架構解決了程序內代碼間調用複雜、代碼職責不清的問題，但這種分層是邏輯概念，在物理上它是中心化的集中式架構，並不適合分佈式微服務架構。DDD 分層架構中的要素其實和三層架構類似，只是在 DDD 分層架構中，這些要素被重新歸類，重新劃分了層，確定了層與層之間的交互規則和職責邊界。
首先，架構向 DDD 分層架構演進，主要發生在業務邏輯層和數據訪問層。DDD 分層架構在用戶接口層引入了 DTO，給前端提供了更多的可使用數據和更高的展示靈活性。DDD 分層架構對三層架構的業務邏輯層進行了更清晰的劃分，改善了三層架構核心業務邏輯混亂，代碼改動相互影響大的情況。DDD 分層架構將業務邏輯層的服務拆分到了應用層和領域層。應用層快速響應前端的變化，領域層實現領域模型的能力。另外一個重要的變化發生在數據訪問層和基礎層之間。三層架構數據訪問採用 DAO 方式；DDD 分層架構的數據庫等基礎資源訪問，採用了倉儲（Repository）設計模式，通過依賴倒置實現各層對基礎資源的解耦。倉儲又分爲兩部分：倉儲接口和倉儲實現。倉儲接口放在領域層中，倉儲實現放在基礎層。原來三層架構通用的第三方工具包、驅動、Common、Utility、Config 等通用的公共的資源類統一放到了基礎層。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
08 | 微服務架構模型：幾種常見模型的對比和分析
課程鏈接：https://time.geekbang.org/column/article/158248
對比DDD分層架構、整潔架構、六邊形架構。
整潔架構
又名“洋蔥架構”，體現了分層分設計思想。在整潔架構裏，同心圓代表應用軟件的不同部分，從裏到外依次是領域模型、領域服務、應用服務和最外圍的容易變化的內容，比如用戶界面和基礎設施。整潔架構最主要的原則是依賴原則，它定義了各層的依賴關係，越往裏依賴越低，代碼級別越高，越是核心能力。外圓代碼依賴只能指向內圓，內圓不需要知道外圓的任何情況。
在洋蔥架構中，各層的職能是這樣劃分的：
- 領域模型實現領域內核心業務邏輯，它封裝了企業級的業務規則。領域模型的主體是實體，一個實體可以是一個帶方法的對象，也可以是一個數據結構和方法集合。
- 領域服務實現涉及多個實體的複雜業務邏輯。
- 應用服務實現與用戶操作相關的服務組合與編排，它包含了應用特有的業務流程規則，封裝和實現了系統所有用例。
- 最外層主要提供適配的能力，適配能力分爲主動適配和被動適配。主動適配主要實現外部用戶、網頁、批處理和自動化測試等對內層業務邏輯訪問適配。被動適配主要是實現核心業務邏輯對基礎資源訪問的適配，比如數據庫、緩存、文件系統和消息中間件等。
- 紅圈內的領域模型、領域服務和應用服務一起組成軟件核心業務能力。
六邊形架構
又名“端口適配器架構”，是微服務架構的淵源。六邊形架構的核心理念是：應用是通過端口與外部進行交互的。這也是微服務架構下 API 網關盛行的主要原因。也就是說，在下圖的六邊形架構中，紅圈內的核心業務邏輯（應用程序和領域模型）與外部資源（包括 APP、Web 應用以及數據庫資源等）完全隔離，僅通過適配器進行交互。它解決了業務邏輯與用戶界面的代碼交錯問題，很好地實現了前後端分離。六邊形架構各層的依賴關係與整潔架構一樣，都是由外向內依賴。
- 紅圈內的六邊形實現應用的核心業務邏輯；
- 外六邊形完成外部應用、驅動和基礎資源等的交互和訪問，對前端應用以 API 主動適配的方式提供服務，對基礎資源以依賴倒置被動適配的方式實現資源訪問。
六邊形架構的一個端口可能對應多個外部系統，不同的外部系統也可能會使用不同的適配器，由適配器負責協議轉換。這就使得應用程序能夠以一致的方式被用戶、程序、自動化測試和批處理腳本使用。
三種微服務架構模型的對比和分析
雖然 DDD 分層架構、整潔架構、六邊形架構的架構模型表現形式不一樣，但這三種架構模型的設計思想正是微服務架構高內聚低耦合原則的完美體現，而它們身上閃耀的正是以領域模型爲中心的設計思想。
圖中的紅色線框，三種架構中都有，它的作用就是將核心業務邏輯與外部應用、基礎資源進行隔離。紅色框內部主要實現核心業務邏輯，但核心業務邏輯也是有差異的，有的業務邏輯屬於領域模型的能力，有的則屬於面向用戶的用例和流程編排能力。按照這種功能的差異，我們在這三種架構中劃分了應用層和領域層，來承擔不同的業務邏輯。領域層實現面向領域模型，實現領域模型的核心業務邏輯，屬於原子模型，它需要保持領域模型和業務邏輯的穩定，對外提供穩定的細粒度的領域服務，所以它處於架構的核心位置。應用層實現面向用戶操作相關的用例和流程，對外提供粗粒度的 API 服務。它就像一個齒輪一樣進行前臺應用和領域層的適配，接收前臺需求，隨時做出響應和調整，儘量避免將前臺需求傳導到領域層。應用層作爲配速齒輪則位於前臺應用和領域層之間。
這三種架構都考慮了前端需求的變與領域模型的不變。需求變幻無窮，但變化總是有矩可循的，用戶體驗、操作習慣、市場環境以及管理流程的變化，往往會導致界面邏輯和流程的多變。但總體來說，不管前端如何變化，在企業沒有大的變革的情況下，核心領域邏輯基本不會大變，所以領域模型相對穩定，而用例和流程則會隨着外部應用需求而隨時調整。把握好這個規律，我們就知道該如何設計應用層和領域層了。架構模型通過分層的方式來控制需求變化從外到裏對系統的影響，從外向裏受需求影響逐步減小。面向用戶的前端可以快速響應外部需求進行調整和發佈，靈活多變，應用層通過服務組合和編排來實現業務流程的快速適配上線，減少傳導到領域層的需求，使領域層保持長期穩定。這樣設計的好處很明顯了，就是可以保證領域層的核心業務邏輯不會因爲外部需求和流程的變動而調整，對於建立前臺靈活、中臺穩固的架構很有幫助。
中臺和微服務設計的關鍵：領域模型和微服務的合理分層設計。
從三種架構模型看中臺和微服務設計
中臺本質上是領域的子域，它可能是核心域，也可能是通用域或支撐域。通常大家認爲阿里的中臺對應 DDD 的通用域，將通用的公共能力沉澱爲中颱，對外提供通用共享服務。中臺作爲子域還可以繼續分解爲子子域，在子域分解到合適大小，通過事件風暴劃分限界上下文以後，就可以定義微服務了，微服務用來實現中臺的能力。表面上看，DDD、中臺、微服務這三者之間似乎沒什麼關聯，實際上它們的關係是非常緊密的，組合在一起可以作爲一個理論體系用於中臺和微服務設計。
1. 中臺建設要聚焦領域模型
中臺需要站在全企業的高度考慮能力的共享和複用。中臺設計時，我們需要建立中臺內所有限界上下文的領域模型，DDD 建模過程中會考慮架構演進和功能的重新組合。領域模型建立的過程會對業務和應用進行清晰的邏輯和物理邊界（微服務）劃分。領域模型的結果會影響到後續的系統模型、架構模型和代碼模型，最終影響到微服務的拆分和項目落地。因此，在中臺設計中我們首先要聚焦領域模型，將它放在覈心位置。
2.微服務要有合理的架構分層
微服務設計要有分層的設計思想，讓各層各司其職，建立鬆耦合的層間關係。不要把與領域無關的邏輯放在領域層實現，保證領域層的純潔和領域邏輯的穩定，避免污染領域模型。也不要把領域模型的業務邏輯放在應用層，這樣會導致應用層過於龐大，最終領域模型會失焦。如果實在無法避免，我們可以引入防腐層，進行新老系統的適配和轉換，過渡期完成後，可以直接將防腐層代碼拋棄。微服務內部的分層方式我們已經清楚了，那微服務之間是否也有層次依賴關係呢？如何實現微服務之間的服務集成？有的微服務可以與前端應用集成，一起完成特定的業務，這是項目級微服務。而有的則是某個職責單一的中臺微服務，企業級的業務流程需要將多個這樣的微服務組合起來才能完成，這是企業級中臺微服務。兩類微服務由於複雜度不一樣，集成方式也會有差異。
項目級微服務：項目級微服務的內部遵循分層架構模型就可以了。領域模型的核心邏輯在領域層實現，服務的組合和編排在應用層實現，通過 API 網關爲前臺應用提供服務，實現前後端分離。但項目級的微服務可能會調用其它微服務，你看在下面這張圖中，比如某個項目級微服務 B 調用認證微服務 A，完成登錄和權限認證。通常項目級微服務之間的集成，發生在微服務的應用層，由應用服務調用其它微服務發佈在 API 網關上的應用服務。你看下圖中微服務 B 中紅色框內的應用服務 B，它除了可以組合和編排自己的領域服務外，還可以組合和編排外部微服務的應用服務。它只要將編排後的服務發佈到 API 網關供前端調用，這樣前端就可以直接訪問自己的微服務了。
企業級中臺微服務：企業級的業務流程往往是多箇中臺微服務一起協作完成的，企業級中臺微服務的集成不能像項目級微服務一樣，在某一個微服務內完成跨微服務的服務組合和編排。我們可以在中臺微服務之上增加一層，下面這張圖，增加的這一層就位於紅色框內，它的主要職能就是處理跨中臺微服務的服務組合和編排，以及微服務之間的協調，它還可以完成前端不同渠道應用的適配。如果再將它的業務範圍擴大一些，我可以將它做成一個面向不同行業和渠道的服務平臺。我們不妨借用 BFF（服務於前端的後端，Backend for Frontends）這個詞，暫且稱它爲 BFF 微服務。BFF 微服務與其它微服務存在較大的差異，就是它沒有領域模型，因此這個微服務內也不會有領域層。BFF 微服務可以承擔應用層和用戶接口層的主要職能，完成各個中臺微服務的服務組合和編排，可以適配不同前端和渠道的要求。
3. 應用和資源的解耦與適配
傳統以數據爲中心的設計模式，應用會對數據庫、緩存、文件系統等基礎資源產生嚴重依賴。正是由於它們之間的這種強依賴的關係，我們一旦更換基礎資源就會對應用產生很大的影響，因此需要爲應用和資源解耦。在微服務架構中，應用層、領域層和基礎層解耦是通過倉儲模式，採用依賴倒置的設計方法來實現的。在應用設計中，我們會同步考慮和基礎資源的代碼適配，那麼一旦基礎設施資源出現變更（比如換數據庫），就可以屏蔽資源變更對業務代碼的影響，切斷業務邏輯對基礎資源的依賴，最終降低資源變更對應用的影響。
DDD 分層架構、整潔架構、六邊形架構都是以領域模型爲核心，實行分層架構，內部核心業務邏輯與外部應用、資源隔離並解耦。
