我們在前面花了大手筆聊子域與限界上下文，不知道作為讀者的您的感受是什麼。當然了，我可不是郭德綱自己給自己叫好。您應該也發現了一個規律，此兩節的內容其實都是在講“分”：子域從業務上劃小，BC從物理上進行劃小。雖然說BC屬於分析模型，但那東西只要一確定您可就得按這個方案進行開發了，所以說其確定了物理上的邊界並無問題。既然是“分”，就使得每一個被劃小的單元都有了自己的專屬地盤兒或者叫勢力範圍。“文明”是一個很有名的策略遊戲，裡面每一個國家都有一個自己的界，不經允許別人是進不去的。這個界在DDD中的意義和遊戲中一樣，除了起到隔離的作用還能有效的解決系統複雜度。本節主打DDD中的隔離其及優點。
DDD中的劃小和隔離機制分為四層：使用子域對問題空間進行劃小、使用BC對解決方案空間進行劃小、通過分層技術對BC進行分塊、使用“聚合”對BC中的領域模型進行分組。前兩項已經仔細盤點過；第三項的概念其實就是傳統三層中的概念；第四項我們後面會詳細介紹，簡單來說就是對領域模型進行分組，任何時候都以組為單位進行領域模型的儲存、修改或刪除。
1、子域隔離
這是第一層的隔離，他的作用就是把一個偌大的領域分成多塊小的，每塊給予不同的優先順序並據此投入不同的資源，實際上這也是一種最為節省資源的系統建議方案。一般來說IT都是成本中心不背收入的，可是胡亂花錢也會讓你被老闆懟。這一層次隔離的目標是業務，人、錢投入策略的隔離是一個方面；最重要的是對於領域範圍的確認：哪些屬於目標業務，哪些和業務無關，可以在子域設計過程中對此兩者進行確認與隔離。
2、BC隔離
BC的隔離是一種物理上的隔離。即便是單體系統中，如果遵守DDD實踐標準，雖然部署的時候都在一起，但系統內部使用了比如Java中的包進行了隔離。他帶來的優勢我們之前也磨叨了一萬多遍，至少就“易於擴充套件和維護”這一優勢也值得你擁有。畢竟對於一個系統來說，建設上面花得錢可是沒有維護花得多，又不是寫“Hello, word”，一次編譯部署就再不管了。這一層次的隔離事關係統前期的建設複雜度和後期的維護花銷，需要花大精力研究。實際上，BC的設計過程也是您對團隊進行建設的工作之一。我們之前說了，需要保證每個BC僅屬於一個人或一個團隊，這不就是對一個大的團隊的人員和責任進行了劃分了嗎？您別忘了BC也是由子域推動設計的，而子域決定了資源的投入，您所做的就是對分配過來的資源做二次整合。通過BC驅動團隊的劃小建設是較為科學的方式，你也值得擁有。就我個人的管理經驗來看，不太喜歡把高水平的多個人放在一起，容易搞事情。一般都是基於子系統進行劃分，每個人負責一塊，也別誰都不服誰。
3、分層隔離
分層隔離估計您是較為熟悉的，就是三層架構中那個所謂的“層”。其主要對程式碼的責任進行了隔離，“責任單一”是核心標準。業務複雜度和非功能需求不同，使得每個BC的架構模式及分層方式也不同。這個層面其實也特別考驗管理者的能力，因為從“層”開始，就需要建立嚴格的開發規範：層的名稱叫什麼、層間訪問限制是什麼、每個層的責任是什麼等……。相關的規範網上也有很多，比較推薦讀一下阿里的程式設計規範範：《阿里巴巴Java開發手冊》。我在這裡以三層架構為例列舉一些比較常見的問題（使用Java語言），看看您或您的馬仔是否有過類似的問題。
- 把快取的操作放到Service層：快取一般屬於持久化的責任，儘管這裡的持久化是在記憶體中。這個問題犯了責任不清的錯誤。
- A包訪問B包的DAO物件：沒有作好訪問限制，容易產生級聯問題，後續作服務的拆分問題也比較大。
- A包的DAO訪問A包的Service：依賴關係不明確，出現反向依賴的情況。
- Spring Web類專案中的RESTful層中，寫入大量業務邏輯：業務邏輯分散，嚴重影響後續的擴充套件，應集中在Service中；同理，DAO中也不得出現非資料相關的業務邏輯。
分層架構分為兩種：嚴格分層，上層只能依賴其直接下層；鬆散分層：上層可以依賴其任意下層。這兩種型別中，都不應該出現下層依賴上層的情況。如果您是三層模式，請使用嚴格分層架構；如果是ODD架構，除Service層外，其它層也使用嚴格分層。
4、聚合隔離
聚合隔離將相關的領域模型組成一個個的工作單元，每個單元間獨立工作，彼此間互為黑盒。這種隔離不僅僅是資料，還包括業務的層次，也就是所謂的達到業務一致性和資料一致性，是整個隔離級別中最小的單元。設計良好的聚合讓業務更聚焦，不僅是開發階段，後續維護起來也相當的方便。修改了一個聚合通常不會影響另外的，減少級聯錯誤的風險。很多時候一些需求的變更，對開發而言就分分鐘搞定了，不過您也別過於樂觀，基於聚合的開發速度比較慢，他的優勢體現在後續的需求變更中，屬於晚熟的漢子。在管理上，請保證一個聚合只由一個人負責。
DDD中的四種隔離理解起來相對簡單，所以使用單獨一章說明是為了對應我們前面所說的DDD的目標：高內聚、低耦合，讓您瞭解這種目標的達成並非只是簡單的使用一些物件導向程式設計就可以搞定的，那僅僅是一種低層次的解耦。
下一節講解架構，敬請期待……