上面一個圖適合所有的需求拿到手以後該想哪些問題或者問哪些問題。因爲有的時候你從老闆或者產品經理那只是拿到
一個大概的需求比如 開發一個網上叫車的系統,系統自動分配離客戶最近的司機。
一、業務領域
1. 業務子域
那麼要分三個業務子域.
身份認證子域 (這應該是所有系統都有的)
打車管理子域(核心業務子域)
報表子域(這也應該是所有系統都有的)
確定業務子域後,就要定義每個業務子域的業務術語。形成開發和業務人員通用的溝通話術。
以打車管理子域爲例
2. 業務術語表
業務規則：
打車：經認證的用戶，打開叫車應用，首先會定位，會在地圖上顯示附近的汽車。用戶發起叫車後，系統會自動通知離客戶最近的司機。用戶到達目的地後，系統自動從用戶關聯的賬戶扣款。
分配司機：系統爲用戶分配一個最近的司機
計費：系統根據用戶所乘車的當前位置進行計費
扣款申請：用戶到達目的地後，系統根據路程的長遠向用戶的銀行賬戶發送扣款申請
打車管理子域依賴於身份認證子領域。只用經過認證的用戶和司機纔可以使用打車管理App，只有有足夠信用額度的用戶纔可以打車。運營報表依賴於打車管理子領域，運營報表目前僅需要從打車管理裏提取用戶的消費記錄，後面估計還會有其它需求。
業務對象：
以打車管理限界上下文，分析參與者
在打車管理限界上下文裏，有兩個明顯的角色：用戶和司機
用戶：在打車App有有效的賬號，有足夠的信用，叫車時要有精確的位置
司機：需要在打車App上註冊的，有有效的身份證明和駕駛證，無不良記錄。收到用戶的訂單後，將用戶從起始點安全地送到目的地。
細緻分析後，我們發現還有一個隱式的對象：訂單。從業務來看，最終的目的還是爲了多拿訂單，從這個角度來看，訂單是比比用戶和司機都重要的業務對象。
業務狀態：
以打車管理限界上下文，分析業務狀態
用戶已叫車、用戶已上車、用戶已到達
二、模型空間
1. 戰略建模：
身份認證限界上下文、打車管理限界上下文、運營報表限界上下文
2. 戰術建模：
聚合：
訂單：是業務的真正關注點。訂單的根實體是訂單本身、本次計費總額，值對象爲用戶的路途（起始位置、終止位置），關聯的實體包括用戶和司機。
用戶：對於用戶，在打車管理這個限界上下文裏，我們只關注用戶的ID、銀行賬戶。根實體是用戶，關聯實體是銀行賬戶，包括賬號、銀行名稱。用戶會發起叫車的事件。
司機:在打車管理限界上下文裏，我們關注的是司機的id，車牌號及司機當前位置。司機當前位置爲值對象。用戶上車後，司機會發出用戶已上車的信號。到達終點時，司機會發起已到達的事件
領域服務：
用戶定位服務：用戶打開打車App時，會自動啓動定位服務，並顯示周圍的司機
分配司機服務：收到用戶叫車的消息後，爲用戶分配一個最近的司機
計費管理服務：用戶上車後，會實時蒐集司機當前位置，並實時計費。當收到已到達終點的信號時，自動向用戶管理賬號發起扣款申請。
領域事件：
用戶已叫車事件：由用戶發起
用戶已上車事件：由司機發起
用戶已到達事件：由司機發起
三、微服務設計
1. 打車管理微服務的設計
微服務裏的微並不是越小越好。微服務和分佈式架構是相關聯的。分佈式架構第一原則是能不做分佈式就不要分佈式，對於微服務，是在能滿足業務需求的情況下，儘可能的不微。所以，對於新的需求，微服務的粒度可以和限界上下文一對一映射。當需求逐漸明晰了後，如果業務需要，微服務的最小粒度可以放到聚合的級別。
因爲是創業公司，對很對需求瞭解都還不夠細，我們微服務粒度和限界上下文對應，現有的版本是V1.0
2. 聚合的設計
3. 領域服務的設計
4. 領域事件
5. 資源庫
定義訂單資源庫類OrderRepository。OrderReporsitory接口目前定義一種方法：findByUserID，返回和該ID相關聯的用戶的所有訂單
OrderRepository基於Repository接口。在Repository接口裏定義三種方法：add、remove、update。用來增加、刪除、更新訂單
四、總結
DDD並不是一個新的架構方法，它在微服務概念提出之前就已經出現了。微服務概念提出後，大家都認爲很好，但是對於如何設計微服務當時沒有給出一個很好的方法，後來，大家套用了DDD的理念來設計微服務，發現這種方法是可行的，DDD的很多理念也和微服務是一致的。