DDD領域驅動設計實踐 —— 業務建模小招數

　　本文結合團隊在ECO（社區服務系統）業務建模過程中的實踐經驗，總結得到一些DDD業務建模的小招數，不一定是完美的，但是對我們團隊來說很有效用，希望能幫到其他人。後面會陸續將項目中業務建模的一些經典例子放上來，分享給大家。

　　ECO系統是線上舊系統，它的建模過程有別於新系統的業務建模。由於背著曆史包袱，ECO的建模過程不是那麼純粹，很容易受到舊代碼的影響，陷入代碼的細節中，初期舉步維艱，靠著小步快跑的方式得到了一些雛形和方法論，後面越來越順，效果還是不錯的。

　　本文為【DDD】系列文章中的其中一篇，其他內容可參考：通過業務系統的重構實踐DDD。 用一句話描述業務情境

　　這句話需要時一個完整的句子，有主謂賓狀，可能還有定語。主語和賓語往往就是我們要找的實體/值對象，位於便是主語對應實體/值對象的行為方法，狀語就是這個case下的商務規則，往往需要歸類到前面的實體行為方法中，至於定語，也會是一些商務規則，同樣要內聚到主語對應的實體中。

　　舉個例子，在社區發帖的業務情境下，我們嘗試使用一句話描述：文章作者只能在其已經加入了的某個圈子下才能發布文章。對照上面的方法，那麼“文章作者”是主語，“文章”是賓語，“發布”是謂語，“只能在其已經加入了的圈子下”是狀語。這樣我們可以得到“文章作者”、“文章”兩個實體，得到“文章作者”有一個“發布文章”的行為方法，得到一條商務規則：文章作者發布文章的前提是加入對應的圈子。 小步快跑，不斷迭代

　　不要想著一口吃一個大胖子，有了模型的雛形就去實現它，在實現的過程中會發現更好的模型，再不斷迭代完善，最後趨於完美。 短而高效的討論很重要

　　一定要有和別人討論，尤其是和有建模經驗的技術專家或者是業務專家進行討論，有針對性的討論，一次討論的點不要太散，聚焦到一個需求模組，逐步挖掘業務模型。

　　推崇的方式是會議形式的討論，面對面的，毫無拘束的各抒己見。

　　討論時間長度不宜超過1小時，和其他會議一樣，超過一小時效率大大降低，最後產出很低；討論一定要聚焦，最好帶著問題去討論，比如讓大家講一下當前建模過程的困惑，對業務的理解。

　　討論過程中，如果遇到無法解決的疑惑或者無法達成一致的問題點時，不能耗費太多時間，可以記錄下來，然後跳過，讓大家回去想想，下次再重新討論。 將你的建模思考過程寫下來

　　業務建模的過程是一個不斷思考的問題，這個思考的過程我建議大家寫下來，不管是將模型草圖畫在白板/紙上，還是通過一篇完整的blog表達出來，都是很好的。這個“寫”的過程會讓自己去梳理模型，去從各個case去觀看模型，去審視模型的不足或者優劣，進而發現更合適的模型。

　　我喜歡使用blog的形式，將每次建模過程記錄下來，包括但不限於：業務建模、業務模型、程式碼範例。 業務建模 —— 描述業務情境，建模的思考過程，最初的幾次可能是不完整的，因為考慮的業務case是不全的，沒有關係，只需要得出符合當前業務case需求的模型即可，後面的迭代中再去完善；我通常會嘗試用一句話去描述這個業務case，從中發現業務模型。 業務模型 —— 通過前面的業務建模思考，最終畫出對應的業務模型草圖，這裡不要整個業務領域大而全的模型圖，而是限定在你正在建模的這個模組或者是這個case下的模型，至於大而全的業務模型圖，到模型相對成熟之後再做整合；只是在建模過程中不斷和關聯模型保持良好溝通即可，當然此類溝通能避免盡量避免，畢竟溝通訊息越多，說明模組耦合越強，這可能是模組劃分不合理的訊號，需要警惕，當然這也不是絕對的，看情況而定。 程式碼範例 —— 程式碼範例並不是要完成整個業務模型的實現，而是通過簡單的代碼將模型demo完成，而且最為重要的一定要通過寫unit test 或者 寫應用服務的形式來類比模型的用戶端調用，這樣能發現很多模型的不足，尤其是發現模型中行為的劃分和設計，更好地完善模型。同時有了代碼demo，大家心裡會更加有底氣，有產出物也更早驗證模型的合理性。但是要警惕千萬不要陷入到代碼的細節上，代碼細節我們可以放到後續的編碼過程中再去完善。 先從複雜的業務case開始建模

　　業務建模先從複雜的業務case開始，直擊業務領域要害，抓中核心，一網打盡。

　　在一個彙總中個，我通常選擇從”根實體”入手，在建模根實體的時候，會逐步涉及到其關聯的其他實體/值對象，順藤摸瓜似的完成了業務建模。

　　另一方面，實踐表明，業務模型中涉及case的複雜度從高到低依次為："增" --> "改" --> “刪” --> “查”，所以我的習慣是先將“增”這個業務case完成，基本上業務模型就八九不離十了，隨後的三個case就變得簡單了，當然其實“查”的case可能不止一個，但是大同小異。 

　　綜合來看，彙總中的“根實體”相對其他關聯實體/值對象，“增”相對與“改”“刪”“查”都是較為複雜的業務case，複雜的搞定了，簡單的自然而然就搞定了，所以建議從複雜的case開始建模。 用業務術語代替技術術語

　　這一點在建模初期，大家容易走入誤區，尤其是在有舊代碼的老系統重構的過程中，大家通常會寫入代碼細節中，這時候建議撇開代碼，單純討論業務模型。讓每個人使用業務模型語言描述自己的問題和想法。這一點做起來蠻難的，但是需要堅持，到後面會發現大家不自覺就會使用模型語言來交流了。這個Evans在《領域驅動設計》一書中提及的“統一語言”相符的。