本文結合團隊在eco（社群服務系統）業務建模過程中的實踐經驗，總結得到一些ddd業務建模的小招數，不一定是完美的，但是對我們團隊來說很有效用，希望能幫到其他人。後面會陸續將專案中業務建模的一些經典例子放上來，分享給大家。
eco系統是線上舊系統，它的建模過程有別於新系統的業務建模。由於揹著歷史包袱，eco的建模過程不是那麼純粹，很容易受到舊**的影響，陷入**的細節中，初期舉步維艱，靠著小步快跑的方式得到了一些雛形和方**，後面越來越順，效果還是不錯的。
這句話需要時乙個完整的句子，有主謂賓狀，可能還有定語。主語和賓語往往就是我們要找的實體/值物件，位於便是主語對應實體/值物件的行為方法，狀語就是這個case下的業務規則，往往需要歸類到前面的實體行為方法中，至於定語，也會是一些業務規則，同樣要內聚到主語對應的實體中。
舉個例子，在社群發帖的業務場景下，我們嘗試使用一句話描述：帖子作者只能在其已經加入了的某個圈子下才能發布帖子。對照上面的方法，那麼「帖子作者」是主語，「帖子」是賓語，「發布」是謂語，「只能在其已經加入了的圈子下」是狀語。這樣我們可以得到「帖子作者」、「帖子」兩個實體，得到「帖子作者」有乙個「發布帖子」的行為方法，得到一條業務規則：帖子作者發布帖子的前提是加入對應的圈子。
不要想著一口吃乙個大胖子，有了模型的雛形就去實現它，在實現的過程中會發現更好的模型，再不斷迭代完善，最後趨於完美。
一定要有和別人討論，尤其是和有建模經驗的技術專家或者是業務專家進行討論，有針對性的討論，一次討論的點不要太散，聚焦到乙個需求模組，逐步挖掘業務模型。
推崇的方式是會議形式的討論，面對面的，毫無拘束的各抒己見。
討論時長不宜超過1小時，和其他會議一樣，超過一小時效率大大降低，最後產出很低；討論一定要聚焦，最好帶著問題去討論，比如讓大家講一下當前建模過程的困惑，對業務的理解。
討論過程中，如果遇到無法解決的疑惑或者無法達成一致的問題點時，不能耗費太多時間，可以記錄下來，然後跳過，讓大家回去想想，下次再重新討論。
業務建模的過程是乙個不斷思考的問題，這個思考的過程我建議大家寫下來，不管是將模型草圖畫在白板/紙上，還是通過一篇完整的blog表達出來，都是很好的。這個「寫」的過程會讓自己去梳理模型，去從各個case去**模型，去審視模型的不足或者優劣，進而發現更合適的模型。
我喜歡使用blog的形式，將每次建模過程記錄下來，包括但不限於：業務建模、業務模型、**示例。
業務建模先從複雜的業務case開始，直擊業務領域要害，抓中核心，一網打盡。
在乙個聚合中個，我通常選擇從」根實體」入手，在建模根實體的時候，會逐步涉及到其關聯的其他實體/值物件，順藤摸瓜似的完成了業務建模。
另一方面，實踐表明，業務模型中涉及case的複雜度從高到低依次為："增" --> "改" --> 「刪」 --> 「查」，所以我的習慣是先將「增」這個業務case完成，基本上業務模型就**不離十了，隨後的三個case就變得簡單了，當然其實「查」的case可能不止乙個，但是大同小異。
綜合來看，聚合中的「根實體」相對其他關聯實體/值物件，「增」相對與「改」「刪」「查」都是較為複雜的業務case，複雜的搞定了，簡單的自然而然就搞定了，所以建議從複雜的case開始建模。
這一點在建模初期，大家容易走入誤區，尤其是在有舊**的老系統重構的過程中，大家通常會寫入**細節中，這時候建議撇開**，單純討論業務模型。讓每個人使用業務模型語言描述自己的問題和想法。這一點做起來蠻難的，但是需要堅持，到後面會發現大家不自覺就會使用模型語言來交流了。這個evans在《領域驅動設計》一書中提及的「統一語言」相符的。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...