戲說領域驅動設計（十四）——補遺

　　寫了好幾章的東西，再回頭讀的時候發現有些內容寫的不理想，沒有表達出自己所想要表達的意思，這次寫一個補遺，把我認為需要重新解釋和著重說明的內容再嘮一嘮，反正我多說兩句，您就可以多理解一些，按此等形式，我感覺下次應該找個小弟當副編輯，專門用于挑錯，廢話不多說，走起……

一、為啥我講的和書上的內容有些不一致？

　　答：四個原因，1，“盡信書,不如無書”，這是這么一個簡單的道理，《領域驅動設計:軟體核心復雜性應對之道》及《實作領域驅動設計》這兩本書可以說是一脈相傳，都是針對復雜的業務給出的解決方案，書中針對戰術模式的講解力度很大尤其是后面這本，我所講的自然要基于經典，實際上也沒有超出它們的圈子，只是里面加入了一些我的理解，這些理解主要是源于作業實踐以及自己的思考，我期望找到一種更為樸素的方式來表達各種模棱兩可的概念，給它們一個明確的定義，這些問題是過去我在學習中碰到的障礙，所以您各位別整天惦記著看代碼，沒有理論的指導代碼也好不了哪去，老馬說什么來著？對，“理論與實踐相結合”，另外，我喜歡在作業中總結和發現一些模式，“人劍合一”不是武功的最高境界，創造武功才是；2，大部分書上所講理論色彩較濃，這是寫書的基本要求，要是著邊就是各種漏洞那豈不是找著被人懟？寫博客要相對隨意一點，只要讀者能明白就齊了，不過隨意不等于寫的東西漏洞百出，這就是坑人了；3，看過很多的書后，理論積累了不少但在落于實踐的時候仍然困難重重，這是個人親身體驗，也說明了理論與實踐中存在著差異，代碼設計與研發是較偏向于實踐的作業，可在實踐程序中卻又沒有嚴格的標準供參考，所以我在試圖找出一種以實踐證明理論的方式來加強學習者對于理論的理解；4，都和別人的一樣，我的這個系列文章就沒有存在的價值了， 那我還寫個毛線啊，

 二、BC的劃分是否有標準？

　　答：無標準，這東西的劃分主觀因素占據的較多，“一千人眼中有一千個哈姆雷特”，不信你找兩個技術差不多的人對同一個系統做BC分割，絕對不一樣（只要是正常的人，不一樣的情況多數也只體現在細節上，大塊上的分割也差不不多少），話雖如此，還是有一些指導性的原則可供使用：1）按業務能力劃分；2）按單一責任原則劃分；3）按業務流程劃分；4）按非功能性需求如性能、資料量、系統更迭速度等，BC是DDD中最為核心的內容，通過子域進行推演而出并為領域模型限定了作業空間，不嚴謹的說，DDD中的大部分概念包括通用語言、戰術模式都幾乎是以BC為單位的，

三、事務腳本到底是不是對DDD的誤用？

　　答：當然不是了，事務腳本是指面向程序編程，使用經典的三層模式，業務代碼集中于應用服務中，一個程序一個程序的撰寫代碼，屬傳統的編程模式，而DDD中最為核心的部分是戰略，使用戰略思想指導系統的建設從起點上就是正確的一大步，系統一般都會存在著大量的基于保存、修改、查詢等簡單業務的微型服務，此時使用事務腳本非常有利于推動專案的前進速度及團隊管理者對于資源的分配，把高級或專家級開發都分配到業務簡單的模塊，把初級開發放到強邏輯服務的上面，相信沒有哪個領導會這么傻，是否應用DDD并不看使用了哪種模式對代碼進行落地，而是看你在戰略上所采用的DDD思想的多寡，這也是一個漸進的、不斷學習的程序，哪怕最初您只用到了10%的DDD理論作為系統建設的指導依據也是一個巨大的進步，任何一個系統都不會是一成不變的，在變化中靈活的、有取舍的使用DDD才是使用正確的姿勢，

四、DDD和微服務架構什么關系？

　　答：一對好基友，我覺得微服務架構是DDD的最佳實踐，尤其是在戰略上面：微服務架構中的每一個服務都對應了一個DDD中的BC；BC的設計可以指導微服務架構中服務的劃分，在我初學DDD的三四年里，當時理解度很不夠，但仍能覺得分出這么多BC后，服務的運維、部署、研發的難度一定會巨大，有的時候一個業務跨多個BC，僅就部署的作業就是個大的難題，可以這么說，DDD出來之時就是一種跨時代的產物，您所能實踐的并不多，而隨著容器、微服務框架等技術的發展，DDD才有了發揮的空間，

五、單體架構是不是違反了DDD思想？

　　答：不存在這個概念，單體與微服務架構是兩種不同的架構風格，具體您使用什么系統與系統的需求、公司的組織結構、資源配給、技識訓累等有著巨大的關系，雖然DDD推崇使用微服務架構，但當條件達不到時不要勉強，還是那句話，DDD思想的重要性要大于某一個具體的戰術模式，我見過一些寫微服務架構技術的文章，極力反對單體甚至將其鄙視的豬狗不如，這種態度就太扯犢子了，微服務架構的確先進，那東西也有它的局限性的，有一次面試，面試官大力的炫耀：我們這兒，每個介面都是一個服務，說這種話的人一般也是近親結婚的產物，一笑置之即可，有這樣一種理論我覺得有點意思：微服務架構能實作服務間的解耦，對應的組織結構也需要進行調整以實作微服務研發團隊間的解耦，只有兩者匹配時才能實作生產力的最大化，我覺得這話老有道理了，這幾年被部門墻和團隊墻折磨的著實夠勁兒，

六、BC的作用到底有哪些？

　　答：三個作用，1，系統部署的基本單位，BC對一個大系統在物理結構上進行了劃分尤其在使用微服務架構落地時效果更為明顯，以BC為單位，大的系統被分割成物理上獨立的、可單獨部署的小服務，僅就其隔離作用所帶來的優勢也是單體不具備的；2，確認了領域術語，讓每個業務概念在BC中的含義是明確的、精準的；3、為領域模型劃分了作用邊界，避免出現超級類，比如電商中的“用戶”概念，在“訂購”BC中主要關注會員、優惠等級等與訂購活動相關的屬性；在“物流”BC中主要關注地址、聯系方式等與識訓、物流相關的屬性；在“營銷分析”BC中會關心其購買記錄等資訊；在“賬戶管理”BC中主要關心其基本屬性的錄入、管理等；在“支付”BC中則需要關注其賬戶余額、交易流水等，如果沒有BC的隔離，您可能就需要建立一個巨大的類包含：地址、優惠等級、聯系方式、購買記錄、商品評價、賬戶金額等全量的資訊，存盤一個客戶資訊搞不好需要建立一個包含100+欄位的表，現實中我遇到過這種情況，沒人敢接手代碼維護，

七、子域、BC等劃分出錯是否會嚴重影響系統的建設質量和速度？

　　答：影響不大，雖然BC的劃分有一定的主觀性，但干這個事情的人都有一定的經驗，即使沒有也可以簡單的根據業務能力劃分出來，很多問題其實都是隨著系統的使用出現的，隨時根據需要對BC進行調整，讓BC的變更與系統的需求演進保持同步，劃分會越來越貼近您所謂的“正確”，這種不停的對代碼進行重構是一種對作業負責的態度，如果您的團隊中有這樣的人就加緊用好了，好的代碼都是通過多次的調整才出來的，

 八、本系統文章后面還有哪些內容？

　　答：除了一般DDD書中所講的戰術部分，還會講一些開發程序中常見但很容易使用不當的內容包括驗證、日志管理等，此外，還會引入一些實際的案例進行演示，同前面的內容一樣，白話居多，另外再多提一句：別著急看代碼，好多理論我自己都琢磨了好久，那都是金不換的，

標籤：領域驅動設計

上一篇：全面解讀 AWS Private 5G 的革新理念

下一篇：戲說領域驅動設計（十四）——補遺