本文書接上回《解決DDD最大難題-如何劃分領域》，關注公眾號（老肖想當外語大佬）獲取資訊：
-
最新文章更新；
-
DDD框架原始碼（.NET、Java雙平臺）；
-
加群暢聊，建模分析、技術交流；
-
影片和直播在B站。
宣告： 本文觀點限定在重業務的軟體系統研發場景下，其它場景不作為本文討論的範圍。
前言
1975 年《人月神話：軟體專案管理之道》首次出版，揭示了一個被程式設計師奉為聖典的法則，認為增加開發者無法線性地縮短軟體交付時間，其中的損耗巨大。時隔近50年，我的軟體交付經驗中卻出現了打破這個法則的現象，我被這些現象深深地震撼，但當時卻沒有聯想到“人月神話”，而最近在思考“如何為大家呈現我們實踐DDD所獲得的收益”時，靈光乍現，意識到實際上我們已經實現了透過增加人數來有效地縮短專案交付週期的能力，我意識到我們真的打破了“人月神話”。
還是那個故事
我在《為了落地DDD，我是這樣“PUA”大家的》一文中，講述了一支團隊落地DDD的實踐經歷，這裡有一個小插曲，在我們重構系統最艱難的時刻，也就是最複雜的訂單模組整個生命週期時，我們的進度壓力很大，團隊期望能夠進行漸進式交付，一塊一塊地交付測試，而訂單的“建立-扣庫存-支付成功”一整個邏輯又相互牽扯，需要完整實現才能提交測試，評估下來，如果這一塊由一個開發者來開發，需要大約三天時間，而我們期望一天能夠完成，於是我們本能地想到了方法：“加人”。但我們也很清楚，按照以往地經驗，加人的損耗肯定是非常巨大的，三個開發者參與進來，一天能夠完成也幾乎是不可能的，但我們沒有別的選擇。
於是，我把三位開發者叫到會議室，按照我們的DDD工作流，花了近一個小時時間，確認了“領域模型”、“建立訂單命令”、“訂單建立成功事件”、“訂單支付成功事件”、各個“事件處理器”邏輯、前端介面定義等設計方案，然後分工分別負責“命令處理器”、“事件處理器”、“前端介面”的開發工作。
令人驚奇的是，基於這樣的分工，團隊很快完成了各自的工作，並在當天下班前，團隊完成了程式碼合併和聯調，意外的進度給我們帶來了一絲絲驚喜，但很快投入到了後續的工作中，並沒有來得及深入思考。
而此後，團隊的交付過程中，類似對於突發事件的應對，也多次復現了這樣的現象，似乎我們的分工可以做到更細的顆粒度，使得團隊能夠透過增加人數的方式縮短需求的交付。
為什麼可以這樣
在我們團隊重新審視這一現象時，我們可以看到：
-
我們將交付過程明確分為了“建模設計”和“程式碼編寫”兩個階段，其中“程式碼編寫”需要的能力是模式化、可複製的
-
我們的程式碼組織方式，非常有利於分工；
“建模設計”和“程式碼編寫”
“建模設計”，是輸入需求資訊，輸出方案的過程，是一個做決定的過程，這個過程，本質上是將“不確定性”儘可能轉變為“確定性”的結論，需要需求方、決策者建立共識，做出設計結論，這個階段無法透過加人來加速，但同時也不需要大量廣泛的參與者，本質上是由“決策者”參與即可。
一旦我們“建模設計方案”確定了，而“程式碼編寫”要做的就是按照“模型設計”編寫確定性的程式碼，這個過程本質上就是“做執行”，團隊成員一旦適應了團隊的程式碼風格和模式，基本不需要太多的思考，就可以寫出“符合預期”的程式碼，因為這個“預期”已經被“建模設計”框定了。而且實踐中我們發現，對於一個新人，透過不到一週的學習和模仿，就可以掌握這個能力。
所以我們開發團隊的整個流程就變成了“做決策”和“做執行”兩件事，也是由“不確定性”到“確定性”的快速收斂的一個過程。
程式碼風格的可協作性
我在《DDD建模後寫程式碼的正確姿勢（Java、dotnet雙平臺）》一文中為大家展示了我們的程式碼組織方式，我在影片《掌握這個模型你就能設計一切》（https://www.bilibili.com/video/BV114421Q7vp） 中也介紹過業務系統中，最核心的就是“命令-事件”，系統的所有業務，都可以對映到這個模型中。用DDD+CQRS+Event Driven的組合，我們發現程式碼被一個個的“CommandHandler”、“EventHandler”拆分成一個個的獨立的業務邏輯處理單元，這些單元的協作，在我們“建模設計”階段已經確定下來，因此，開發者要做的就是完成這一個個填空，就完成了程式碼的編寫，心智負擔非常小。
我們分工的最小顆粒度，就是這一個個的“CommandHandler”和“EventHandler”，這比傳統的CRUD按模組分工的顆粒度要細緻地多，也就意味著，我們團隊可以更細粒度地調配人力，這其中的損耗卻幾乎可以忽略不記。
我們甚至規定，“當你寫程式碼不舒服時，大機率是建模設計出了問題”，要求開發者反饋並由設計者及時修改迭代模型設計，儘可能地確保開發時，程式碼的上下文能夠獲取到支撐實現邏輯單元目標的資訊，從而使得整個開發過程是絲滑的。
回到主題
在我們實踐DDD的過程中，我們意識到，在“程式碼編寫”環節，我們可以非常靈活地調配人力資源，哪怕是被臨時調入專案的開發人員，也可以高效地按照設計完成程式碼的編寫，這其中的損耗幾乎可以忽略不記。
基於這樣的情況，我們認為，一支研發團隊，就可以實現一個建模設計師加上多個實現開發者這樣的模型，而這個團隊模型，我相信也是很多團隊期望的但又很難把協作效率提升上來。
現在看來，我們的實踐做到了，所以，我想，人月神話不再是神話。