本文書接上回《DDD是軟件工程的第一性原理？》，關注公眾號（老肖想當外語大佬）獲取信息：
- 最新文章更新；
- DDD框架源碼（.NET、Java雙平台）；
- 加羣暢聊，建模分析、技術實現交流；
- 視頻和直播在B站。
假DDD的特徵
在開始之前，考慮到目前關於DDD的資料非常多且雜，我們需要具備分辨的能力，確保不被誤導。看過本系列文章的朋友，對我們是如何看待DDD的會有一定的感受，這裏我們列舉一下我們認為的假DDD的特徵，供大家參考：
- 堆砌抽象詞彙，讓人不明覺厲的
- 説DDD只有高級開發者才適合的
- 説DDD很難落地的
- 説只有複雜項目才適合的
- 説只能憑經驗的
適合人羣
首先我們認為“領域驅動設計是一種價值觀”，那麼理解並能夠實踐DDD的前提，認可這種價值觀，既然如此，説明第一步的起點，是沒有門檻的，只要你主觀上認同即可，所以我們認為DDD適合軟件工程工作相關的各個角色來學習和實踐，包括但不限於：
- 期望從事軟件領域的在校學生
- 各個層級的軟件工程師
- 產品經理
首先軟件工程師得懂DDD，這是毋庸置疑的，我隱約有一種感覺，真正的DDD就是軟件工程的唯一正解，不少後端老司機一直苦於隨着時間的推移，系統代碼快速腐化的問題，而DDD正是對抗這種腐化的底層邏輯，是軟件工程的第一性原理。
對於學生羣體，我接觸的案例證明，對於軟件領域的新人，反倒更容易理解和接受DDD，這是因為目前主流的軟件設計指導，很多都指向了與DDD相反的方向，新人因為沒有被這些信息所誤導，沒了先入為主的思維枷鎖，很自然地容易接受更有收益的軟件設計思想。
軟件工程師最喜歡的產品經理，大概率是懂一些技術的產品經理，而如果對DDD的概念有所理解的產品經理，我相信在需求分析、產品設計、模型設計方面能夠與工程師更容易相互理解並建立共識，大家一定還記得之前文章所説的“擬人化建模溝通法”，在這裏更是能發揮巨大的作用，使得“需求-模型”的一致性得到更好的保障。
學習路徑
下圖展示了一個學習的循環迭代，我認為可行幾點如下：
- 學概念，通過系列文章、視頻，構建基本概念認知
- 學實踐，使用DDD框架做代碼練習
- 做驗證，一個教練指導並不斷地實戰體驗，迭代認知和行為
學概念
我們認為DDD的概念是具體的，是容易理解和實踐的，如果你有通讀本系列的前文，那麼一定會有所感受，《老肖的領域驅動設計之路》，其中關鍵的概念觀點包含但不限於：
- 領域驅動設計是一種價值觀
- DDD原則
- 邊界明確是最重要的事
- 一致性比正確性更重要
- DDD是軟件工程的第一性原理
- 系統的複雜度來自元素的數量和元素之間的關係
- 複雜度守恆定律
- 擬人化建模溝通法
- 不要複用
- 萬能模型之“命令-事件”
- 如果寫代碼彆扭，大概率是建模出了問題
學實踐
學實踐，就是不斷地建模設計、代碼實現，目前我們已經為Java、.NET生態分別提供了DDD戰術框架，基於戰術框架，並配套了工程模板，期望能夠幫助你的團隊在沒有技術負擔的狀態下體驗DDD帶來的優勢和收益，從而增強團隊的DDD認知：
Java：https://github.com/netcorepal/cap4j
.NET: https://github.com/netcorepal/netcorepal-cloud-framework
關於教練
首先教練不是必須的，但一個好的教練，可以讓你大大加速對DDD的認知和應用，教練的核心作用就是：
- 引導認知理解
- 教授實踐方法
- 驗證學習成果
那麼對於一個好教練，我認為最關鍵的就是：能夠判斷決策（需求分析、建模設計、代碼實現）是否符合DDD價值觀。要做到這點，那麼一個好教練大概率滿足以下特徵：
- 對DDD的理解準確
- 有實踐的成功經驗
哪裏找一個好教練呢？（廣告時間）在你眼前就有這麼一位，關注我，我在直播間就是扮演教練的角色，歡迎互動交流。
視頻與直播：
https://space.bilibili.com/6733407如何判斷成果
學習過程中，很重要的就是成果的正向反饋，關於DDD的學習，以我的經驗來看，雖然無法給出明確的可量化的指標，但下面幾點可以幫助你從主觀上判斷是否有進展：
- 對需求和系統有掌控感了
- 需求-模型-代碼越來越一致了
- 寫代碼感覺絲滑了
- 代碼BUG率有顯著的改善
最後
歡迎交流實踐經驗，持續提高開發者的幸福感。
