原文鏈接：DDD模型落地思考
DDD模型落地難的問題
第一次聽到“DDD模型難落地”，是剛轉到諮詢的第一個年會上。我當時內心的OS是“DDD模型難落地？怎麼會？我都落地了3年多了，難道我一直都是在做假的DDD？”。然而，很快，我就啪啪打臉了。參加完年會，我的第一個基於DDD重構的諮詢，卡在了DDD戰術設計落地上。
那麼爲什麼DDD模型在客戶那兒比在我們自己更難落地？
做DDD建模的目的不同
- 爲了更好的支持業務
我們團隊建模主要是爲了讓模型能夠更適用現有的業務。沒有最好的模型，只有最適合的模型。只要將所有業務帶入到模型中去驗證能符合，就是好模型。 - 爲了獲得一個更好的模型
客戶做DDD建模，基本都是爲了爲了獲得一個更好的模型。爲了獲得一個更好，更全的模型，往往會引入未來一段時間內的業務需求，同時引入多方人員參與建模。這個過程建出來的模型可能會出現對當前的業務支持沒有那麼好，而是一個更適合“未來”的模型。因此，當想把現有模型進行修改時，可能會出現不適用的情況。
做DDD模型的改造方式不同
- 小規模/迭代式落地
當模型建好以後，我們團隊會將現有模型和原有模型進行比對。然後制定改造計劃，對現有模型一步一步的改造成我們期望的模型。然後將各個步驟拆分成技術卡，分散到各個迭代中去。 - 大規模/一次性落地
當模型建好以後，對比現有模型和原有模型後，客戶一般會有2種方式進行改造- 拉個獨立的分支進行修改，修改完合併回原來的分支。然而，合併回原分支的時候，往往需要解決過多的衝突。最終可能導致放棄。
- 直接在原有分支進行修改，改完模型後，需要花很長時間去修復壞了的功能，導致整個應用在很長一段時間不可用。
做DDD建模的規模不同
- 輕量級
我們團隊建模的時候，基本都是輕量級建模。每個迭代（2週一個迭代）開始的時候，基於新增的需求，我們會簡單的做一次模型匹配，看現有的模型是不是還能滿足需求。如果是微調，模型修改會通過Code Review的時候，跟大家進行同步。如果需要大改或者比較複雜，我們會讓2-3個核心人員（開發，測試，業務）進行DDD模型設計，並將結果同步給大家，並做進一步的答疑（大約佔用大計1-2小時的時間）。整個過程佔用的時間不會太多，不會影響項目交付的進度，每次模型修改不會太大，全員信息同步的效率高。 - 重量級
客戶的建模的時候，基本都是重量級建模，客戶基本上會把現有系統的整個/大部分功能進行梳理，然後對整個/大部分功能進行建模，整個過程耗費時間久，參與人員多，且基本都是脫產建模。常常會遇到在建模的過程中，某些人員只負責部分模塊的開發和設計，對其他模塊不瞭解，從而容易跑神，造成同步效率低。同時，大家都脫產去建模，項目交付壓力會很大。
DDD模型如何正確落地
- 輕量級建模
以迭代爲週期，每個迭代進行增量的建模，降低建模成本。 - 小步改造
不要想着花一段時間專門改模型，改架構。單純的做技術卡是沒有業務價值的，將架構改造，模型重構的事情分成多個小步驟，融入到每個迭代中，一步一步的做。 - 沒有銀彈，60分就可以了
不要想着建出一個很好的模型，再也不用改了。隨着時間的變化，業務形態的變化，我們的模型一定會跟着變化的，所以，只要能滿足現有業務的模型就是好的模型。 - 工具可視化模型
通過工具可視化展示代碼模型，幫助大家直觀的進行模型分析和模型守護。