本文結合團隊在ECO（社區服務系統）業務建模過程中的實踐經驗，總結得到一些DDD業務建模的小招數，不一定是完美的，但是對我們團隊來說很有效用，希望能幫到其他人。后面會陸續將項目中業務建模的一些經典例子放上來，分享給大家。
ECO系統是線上舊系統，它的建模過程有別于新系統的業務建模。由于背著歷史包袱，ECO的建模過程不是那么純粹，很容易受到舊代碼的影響，陷入代碼的細節中，初期舉步維艱，靠著小步快跑的方式得到了一些雛形和方法論，后面越來越順，效果還是不錯的。
本文為【DDD】系列文章中的其中一篇，其他內容可參考：通過業務系統的重構實踐DDD。
用一句話描述業務場景
這句話需要時一個完整的句子，有主謂賓狀，可能還有定語。主語和賓語往往就是我們要找的實體/值對象，位于便是主語對應實體/值對象的行為方法，狀語就是這個case下的業務規則，往往需要歸類到前面的實體行為方法中，至于定語，也會是一些業務規則，同樣要內聚到主語對應的實體中。
舉個例子，在社區發帖的業務場景下，我們嘗試使用一句話描述：帖子作者只能在其已經加入了的某個圈子下才能發布帖子。對照上面的方法，那么“帖子作者”是主語，“帖子”是賓語，“發布”是謂語，“只能在其已經加入了的圈子下”是狀語。這樣我們可以得到“帖子作者”、“帖子”兩個實體，得到“帖子作者”有一個“發布帖子”的行為方法，得到一條業務規則：帖子作者發布帖子的前提是加入對應的圈子。
小步快跑，不斷迭代
不要想著一口吃一個大胖子，有了模型的雛形就去實現它，在實現的過程中會發現更好的模型，再不斷迭代完善，最后趨于完美。
短而高效的討論很重要
一定要有和別人討論，尤其是和有建模經驗的技術專家或者是業務專家進行討論，有針對性的討論，一次討論的點不要太散，聚焦到一個需求模塊，逐步挖掘業務模型。
推崇的方式是會議形式的討論，面對面的，毫無拘束的各抒己見。
討論時長不宜超過1小時，和其他會議一樣業務建模用哪些圖，超過一小時效率大大降低，最后產出很低；討論一定要聚焦，最好帶著問題去討論，比如讓大家講一下當前建模過程的困惑，對業務的理解。
討論過程中，如果遇到無法解決的疑惑或者無法達成一致的問題點時，不能耗費太多時間，可以記錄下來，然后跳過，讓大家回去想想業務建模用哪些圖，下次再重新討論。
將你的建模思考過程寫下來
業務建模的過程是一個不斷思考的問題，這個思考的過程我建議大家寫下來，不管是將模型草圖畫在白板/紙上，還是通過一篇完整的blog表達出來，都是很好的。這個“寫”的過程會讓自己去梳理模型，去從各個case去觀看模型，去審視模型的不足或者優劣，進而發現更合適的模型。
我喜歡使用blog的形式，將每次建模過程記錄下來，包括但不限于：業務建模、業務模型、代碼示例。
先從復雜的業務case開始建模
業務建模先從復雜的業務case開始，直擊業務領域要害，抓中核心，一網打盡。
在一個聚合中個，我通常選擇從”根實體”入手，在建模根實體的時候，會逐步涉及到其關聯的其他實體/值對象，順藤摸瓜似的完成了業務建模。
另一方面，實踐表明，業務模型中涉及case的復雜度從高到低依次為："增" --> "改" --> “刪” --> “查”，所以我的習慣是先將“增”這個業務case完成，基本上業務模型就八九不離十了，隨后的三個case就變得簡單了，當然其實“查”的case可能不止一個，但是大同小異。
綜合來看，聚合中的“根實體”相對其他關聯實體/值對象，“增”相對與“改”“刪”“查”都是較為復雜的業務case，復雜的搞定了，簡單的自然而然就搞定了，所以建議從復雜的case開始建模。
用業務術語代替技術術語
這一點在建模初期，大家容易走入誤區，尤其是在有舊代碼的老系統重構的過程中，大家通常會寫入代碼細節中，這時候建議撇開代碼，單純討論業務模型。讓每個人使用業務模型語言描述自己的問題和想法。這一點做起來蠻難的，但是需要堅持，到后面會發現大家不自覺就會使用模型語言來交流了。這個Evans在《領域驅動設計》一書中提及的“統一語言”相符的。