對DDD使用的一些建議
群里經常看到類似於「看了DDD之後就不會寫程式碼了」的情況，趁最近學車的間隙，寫寫我的看法。
關於這個事兒，我是覺得：當沒有DDD的時候，如果你知道怎麼做，那就那麼做好了，不要考慮DDD。
當然不是說學了不用，而是在無法直接與實際做對應的情況下，先不要對應，慢慢來。這是一套方法論，而不是具體的方法，它更多的是給一個對當前系統複雜性手足無措的人一個思路。其中聚合那一部分只是個前提，並不是DDD的重要部分。
初做設計，學習DDD的時候，邊看書可以邊將內容與面向對象的各種設計原則、基本準則做對比，儲備相關知識，領會面向對象的精神。學習設計的時候，完全沒必要去考慮DDD該如何落實到程式碼這種程度。在我看來，DDD就是一種面向對象的最佳實踐，就像設計模式是面向對象基本原則的最佳實踐一樣，當一個新手不知道如何寫程式碼，可以選擇性的模仿。
雖說不是系統簡單就用不了DDD，「每行程式碼都是一個設計」，但是初學者應該是在手中的系統變得越來越複雜，涉及的業務對象越來越多而感到困擾的時候，才是能真正利用上DDD。一個新進的設計者這時藉助DDD的思路去規劃業務、去與其他團隊協作，或許才能體會出其中的好處。
當年初出茅廬，遇到了些業務龐大、邏輯複雜的系統。在思考如何解決複雜性的時候，其實已經將業務對象封裝成類似「聚合、聚合根」的形式了。只是項目推進的過程遇到了很多問題，也沒有根據變化情況區分層次。然後順著這些問題找到了DDD，它系統地解決了我的問題，並指出了一個方向。
雖說理想情況下是系統逐漸變得複雜，通過敏捷的方式按部就班的演進系統。但是也會有半路接手的問題，這些都是要在方法論思路的指導下靈活掌握的。至於一開始就很複雜的系統，完全可以在T型集成之類的方法下，持續敏捷的去做，就當作是系統再逐漸複雜也無不可。
雖說學習都是從模仿開始的，但DDD應該是模仿其解決複雜性的思路，而不是實現的程式碼，開發技巧這種層面的事兒。這方面，公眾號里只發過兩篇(以前部落格園部落格還寫過一些，不過沒整理過來)，大概談過這類內容，大家可以參考：《DDD概述》、《觀畫有感之軟體開發》。雖然現在看來也有些可以商榷的地方，但是對初學者應該還是不錯的。
最後，我想順便說一下和微服務的事兒。我認為DDD和微服務是完全不同的兩個東西，雖然在一些條件下，它們比較契合。微服務更多的是從技術和團隊組織結構上劃分的，DDD的子域更多的是從業務邏輯、業務穩定程度方面劃分，很多時候確實會有重疊。但學習DDD的時候還是忽略這些重疊比較好，混淆了就出不來了。如果有特別情況，比如中台的業務邏輯按各自領域提供服務，而某一個特別功能的訪問量奇大，那它的部署，服務間引用與業務的緊密程度可能並不對應，會需要取捨。
