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