DDD設計何時適可而止？

banq發表於2022-04-02

無論是敏捷和瀑布，軟體開發都有一個設計過程，實際也是瞭解知識準備過程，屬於坐而論道，那麼什麼時候動手開幹？

1. 首先，動手開乾的標誌是什麼？見這篇文章：

按技術職責還是按領域職責來構建程式碼？
文章裡談了程式碼如何組織包模組，也就是com.jdon.XXX的設計，這個XXX設計不是拍腦袋想出來的，而是基於你對領域的理解，如果你對業務領域不理解，你會直覺按照技術職責劃分，或者按照團隊劃分，如果你業務領域理解了，那麼會按照領域職責劃分。

2. 那麼理解業務領域的標誌是什麼？見這篇文章：

如何實現軟體設計中的高凝聚和松耦合？
你如果能找出業務領域的高內聚和低耦合的劃分，基本說明你已經對業務領域理解了，那麼com.jdon.XXXX的包層次結構就大概出來，可以分工開幹了。

3. 但是，關鍵是在內聚和耦合了，這個問題是否好解決呢？
不一定，因為這取決於上下文環境：

DDD設計何時適可而止？
遠看一隻虎，近看一條狗！
沒有上下文的資料就是噪音！ 上下文為王
這是資料科學領域的格言，那麼同樣適合在人對世界的認知中。
高聚合和低關聯是依據上下文不同而不同的，也就是根據上下文環境做判斷的，這是難點，因為如果你沒有發現上下文的相關性，如同上圖中，你沒有發現鐵柵欄投影到狗身上引起的條紋，這個上下文因素忽視了，那麼內聚模型就建模建錯了。

4. 那麼到這裡有什麼訣竅嗎？如果有，機器學習就戰勝人類了，變成通用人工智慧了。
所以，這就到藝術邊緣，能子領域能聚合在一起就好了，單一功能職責劃在一起就可以了，不必精益求精，因為已經到了藝術地步，不屬於數學，再死磕就過了。
而且靈感不是死磕中出現，而是少做並學習後才出現：

程式設計師應該少做些"工作"

5. 好了，我們也死磕到此為止，話題一轉，回到按照領域職責劃分上：
com.jdon.xxxx.xxx.xxx.xxx的子包出來後，團隊就要對齊這個領域劃分包，每個團隊承包一個子包，這就是：

DDD與團隊拓撲以及微服務之間的關係圖

6. 最後，再次提醒：

簡單軟體架構的一些好處

相關文章