本文書接上回《主觀與客觀，破除DDD憑經驗魔咒》，關注公眾號（老肖想當外語大佬）獲取資訊：
-
最新文章更新；
-
DDD框架原始碼（.NET、Java雙平臺）；
-
加群暢聊，建模分析、技術實現交流；
-
影片和直播在B站。
開個玩笑
“我不是針對這一個問題，我是說所有的反DDD模式都是垃圾”，作為教練，在團隊中我時常用這樣的玩笑來調侃不符合DDD價值觀的判斷邏輯和決策結果，並指出具體不符合的點在哪裡，由於大家已經相互非常瞭解，能夠很快反應過來並建立共識，從而不斷修正決策邏輯和決策結果，使問題的範圍和解決方案收斂在一個確定的範圍內，持續地保持對系統複雜度的掌控。
===
前提條件
首先需要對齊我們討論的場景，主要在下面的條件範圍內：
-
軟體系統是長期迭代的
-
軟體系統是業務向的系統
在這個條件範圍下，我們可以解讀為：
-
我們認為迭代成本是軟體成本的重要組成部分
-
我們認為自己打造的軟體系統的業務複雜度高於技術複雜度
成本與複雜度
為了儘可能降低系統迭代的綜合成本，本質上就是掌控系統複雜度，而系統複雜度由業務複雜度和技術複雜度共同構成。
為了實現“掌控系統複雜度”的目標，基於複雜度守恆定律，我們有以下觀點：
-
複雜度不可被消除，只可被轉移
-
尊重業務固有複雜度
-
避免引入額外技術複雜度
而我們在《關於領域驅動設計，大家都理解錯了》一文推導過關於複雜度的結論：
-
系統複雜度與元素的數量和元素的關係有關；
-
元素的關係對系統複雜度的影響遠遠大於元素的數量所產生的影響；
===
核心觀點
如果你已經跟隨《老肖的領域驅動設計之路》系列一路讀過來，那麼我們接下來的推導過程就需要在之前構建的認知基礎上進行，這裡列出核心觀點以供複習：
-
領域驅動設計是一種價值觀
-
DDD價值觀：邊界明確是最重要的事
-
軟體長期主義：可維護性是最重要的事
-
DDD是軟體工程的第一性原理
基於上面這些觀點，DDD的核心，就是掌控系統元素之間的關係，明確邊界，將複雜度控制在一個個有限的範圍內，完全匹配軟體工程的成本控制的邏輯，那麼是不是就可以得出下面的結論：
-
符合DDD價值觀，意味著符合軟體工程的成本利益
-
反DDD的模式，意味著不符合軟體工程的成本利益
那麼回到本文的標題，“所有反DDD模式都是垃圾”，更準確的描述應該是“所有反DDD模式都是不符合軟體工程成本利益的”，我認為，這個邏輯是成立的。
如果你認同《DDD是軟體工程的第一性原理？》一文的觀點，那麼同樣也能得出這樣的結論，違反軟體工程第一性原理，當然會適得其反，走向系統快速失控的深淵。
所以，很抱歉，如果你的軟體設計思維，沒有圍繞著“明確和維護邊界”來開展，那麼大機率是錯誤的價值判斷思路，系統的複雜度大機率也很難被掌控，而具象化出來的現象，就是我們常說的“迭代不動了”。
那麼，快來和我一起實踐DDD吧！