本文書接上回《學習真DDD的最佳路徑》，關注公眾號（老肖想當外語大佬）獲取資訊：
-
最新文章更新；
-
DDD框架原始碼（.NET、Java雙平臺）；
-
加群暢聊，建模分析、技術實現交流；
-
影片和直播在B站。
神秘的“憑經驗”
一千個人眼中有一千個哈姆雷特，每個人的經歷不同，認知不同，那麼看待哈姆雷特的角度和感受也不同。在軟體工程領域，也有著名的關於如何做好軟體設計的觀點：“憑經驗”。然而，“憑經驗”就意味著不可複製，如果軟體設計只能憑經驗，那還不如說是撞大運。
讀過本系列前文《老肖的領域驅動設計之路》的朋友，應該知道，我對此是持相反的觀點的，今天透過幾分鐘的篇幅，呈現我的理解，嘗試破除憑經驗的魔咒。
憑經驗與主觀判斷
首先，我認為依靠經驗來決策，本質上是一種主觀判斷，尤其是那些無法由客觀事實和邏輯推導的判斷和無法建立普遍共識的判斷。至少憑經驗這個方法本身，是主觀的。試想一下，如果人們都僅僅依靠自己的過往經驗來做判斷，那麼“靠左走好”和“靠右走好”就會成為普遍的觀點衝突，而這個衝突的背後就是，“我不要你覺得，我要我覺得”。
當然更準確的說法是“憑經驗”意味著不能絕對客觀。
主觀與客觀
主觀的反面是客觀，客觀意味著觀點基於客觀事實，基於符合事實的推導邏輯鏈，也就意味著客觀決策，能夠在一定的規則範圍內建立共識的判斷結果，那麼我們可以得到如下觀點：
-
主觀判斷對應非標，無法標準化
-
客觀判斷對應標準，可以標準化
如果對於一件事情可以標準化判斷，是不是意味著這件事是可執行、可落地的？
需求分析和建模設計中的主觀與客觀
先舉個例子，假設我們有個需求：“整理房間裡的物品”，那麼我們的解決方案可以是：“取N個收納箱，把物品一個個放進去”，那麼這裡就有一些主觀和客觀的決策在裡面。
主觀的部分有：
-
決定用多少個收納箱
-
哪些物品放哪個收納箱
客觀的部分有：
-
收納箱之間相互獨立
-
一個物品不會被放在兩個收納箱裡
如果我們將物品和收納箱對應到建模設計中，收納箱裡裝物品，而軟體是領域模型負責需求點的滿足，則可以這樣對應：
-
物品對應需求點
-
收納箱對應領域模型
基於這樣的對應，我們可以推匯出我們在需求分析和建模時候，哪些部分是主觀的，哪些部分又是客觀的。
主觀的部分：
-
有多少個領域模型
-
哪些需求點由哪個領域模型來滿足
客觀的部分：
-
領域模型之間相互獨立
-
一個需求點不被兩個領域模型來滿足
回到領域驅動設計
如果你是跟著我的思路讀到這裡，並且認同前面的推導邏輯以及系列前文的核心觀點“領域驅動是一種價值觀”，這種價值觀是“邊界明確是最重要的事”，最精彩的部分來了，你會發現，我們前面推匯出來客觀的部分，是完全契合領域驅動設計價值觀的。而主觀的部分，甚至都不曾在領域驅動設計概念裡提及。
所以，回到文章的開頭關於憑經驗的說法，我們認為軟體設計中，憑經驗的部分不會影響領域驅動設計價值觀的踐行。
那麼我們的核心觀點是，一個決策是否符合領域驅動設計，是可以客觀判斷的，領域驅動設計客觀上可以落地執行，並不依賴人的經驗。
主觀的部分不重要嗎
我們再把建模時候主觀的部分列出來：
-
有多少個領域模型
-
哪些需求點由哪個領域模型來滿足
這部分當然也很重要，經驗越豐富越容易更快速地定義出職責分配更準確的模型，但它不如“邊界明確”這件事重要，因為“邊界明確”解決的是結構性的問題，而主觀的決策部分解決的是“區域性準確性問題”，這就好比建築裡的“承重牆”和“隔間牆”之間的關係，顯然承重牆決定了整體的架構，對建築最終效果以及未來改造成本有更深遠的影響。
後續
到此，《老肖的領域驅動設計之路》系列的整體邏輯已經接近閉環，下一期將從“反DDD”的視角來剖析軟體行業的亂象，以及開發者可以努力的方向。