本文書接上回《反DDD模式之“複用”》，關注公眾號（老肖想當外語大佬）獲取資訊：
-
最新文章更新；
-
DDD框架原始碼（.NET、Java雙平臺）；
-
加群暢聊，建模分析、技術實現交流；
-
影片和直播在B站。
背景
最近直播的時候，看到一條留言，問我是否有關於如何劃分領域的文章，翻看了一下，發現關於這麼重要的問題，居然沒有專門、認真、細緻地講過。也難怪不少人說不接地氣，整天搞些虛頭巴腦的東西。但沒有講的原因，我還是要為自己辯解幾句的，不是不想講，也不是不能講，而是我潛意識裡覺得本質的東西講明白了，這個問題就太簡單，沒必要講。
當然，如果你是我的老粉絲，關注過我過往輸出的內容，那麼你也知道，早前也是有在我們FireUG社群的DDD公開課裡專門講這個話題（【DDD 領域驅動設計 | PART V：如何識別領域邊界?】 https://b23.tv/sRqAC8O ）。
時至今日，我自己對於軟體工程的認知又經過了一輪迭代，重新來解讀一下這個問題。
先說答案
問：如何劃分領域？
答：基於如下兩條可以得出一個領域：
-
當你有一個需求，叫建立xxx時，那麼這個xxx就是一個聚合根；
-
我們可以視作一個聚合根就是一個領域；
如何解讀
例如，一個系統中，需要建立一個使用者，那麼使用者就是聚合根，使用者就是一個領域，諸如此類的需求是非常容易識別的，我相信不論你的軟體設計經驗如何，都是可以基於這個規則來做出判斷的。
當然你會說，我有一個需求是給使用者建立收貨地址，那麼這個收貨地址是不是聚合根呢？這就要看，你建立的是“收貨地址”，還是“使用者的收貨地址”，如果你認為是“收貨地址”，那麼它就應該是聚合根，如果你認為是“使用者的收貨地址”，意味著這個需求，僅僅是給“使用者的收貨地址屬性”新增新值。
又比如訂單，你是認為是“建立訂單”還是“使用者的訂單”呢？我想大部分人會直覺上選擇“建立訂單”，為什麼會有這樣的直覺？我想，你一定會得出一個答案，“訂單”足夠複雜。
那麼這樣看來，理解業務的標準是不是又變成了“複雜的就分開”這麼一個不太好衡量的判斷呢？不妨你把它反過來看，就有答案了，那就是“簡單的就合併”。
還是前面的例子，還是收貨地址，因為存在一個需求叫“建立收貨地址”或者“建立使用者的收貨地址”，我分不清楚，沒關係，我們就預設視作存在這個聚合根，存在“收貨地址”這個領域。然後我們在考慮，這個領域獨立存在對我們有沒有好處，這個領域合併進“使用者”領域，我們是否可以接受。如果我們有充分的把握說合並沒有問題，那麼就合併，否則，就讓它成為一個領域，並保持邊界明確。
為什麼基於建立xxx來判斷
也許，你會有疑問，為什麼基於“建立xxx”需求來判斷聚合根？核心邏輯就是這類需求，意味著xxx不可分割的整體，意味xxx就是最小的完整範圍，相當於我們基於這類需求，識別出了系統內的“原子單元”，就像一片片樂高積木一樣，不可再拆分。
本質是什麼
在我看來，這樣劃分領域的方法的本質，就是我們先認為邊界就在那裡，凡是有建立xxx的需求，即存在一個領域，只是說我們經過思考，某些領域合併進去是比較確定複雜度是可以掌控的，那麼我們才做出了合併領域的決定。
所以，與其說這是如何劃分領域，不如說，這是思考什麼時候合併領域。
底層價值觀的支撐
如果你是跟隨本系列文章一路閱讀過來的話，一定知道，我對於軟體設計的核心觀點是：
-
DDD是一種價值觀
-
保持邊界明確是最重要的事
那麼你就會發現，前面說的方法，是完全契合這個價值觀的，我們首先明確出組成系統的一個個“原子單元”，識別出它們，然後再謹慎地進行合併，在沒有把握的情況下，優先保持領域邊界明確，避免它們之間的耦合。
而信奉這個價值觀的依據則是我們對於複雜度的理解，這在前文也有詳細講解：
-
系統複雜度與元素的數量和元素的關係有關；
-
元素的關係對系統複雜度的影響遠遠大於元素的數量所產生的影響；
說到底，核心目的仍然是為了保持我們對系統複雜度的掌控，因此我們謹慎地為系統內的領域之間“建立耦合”。
完整操作方法
那麼，如果你和我一樣，認同DDD是價值觀，保持邊界是最重要的事，我們完整的操作方法就是：
-
當你有一個需求，叫建立xxx時，那麼這個xxx就是一個聚合根；
-
我們可以視作一個聚合根就是一個領域；
-
當我們非常大把握可以掌控一個領域合併後的複雜度時，可以考慮合併這兩個領域；
結尾
以上就是我們團隊日常分析需求、設計方案和建模的實際操作方法，如果你贊同或者有共鳴，也很期望您將文章分享給更多的朋友。如果你持有不同的觀點和視角，也歡迎與我討論，我相信，至少持續提升開發者幸福感這個方向，咱們是有共識的。