虛擬一家類似于XX打車的創(chuàng)業(yè)公司，要開展業(yè)務(wù)，首先要開發(fā)一套網(wǎng)上叫車的系統(tǒng)。使用DDD的思想進行設(shè)計，并用SpringCloud框架進行開發(fā)。本節(jié)主要講如何通過業(yè)務(wù)領(lǐng)域驅(qū)動微服務(wù)的設(shè)計
公司名稱：打車易公司
公司愿景：讓天下沒有難打的車
通過與公司核心團隊一番交談，我們了解到了主要需求是：客戶在網(wǎng)上叫車，系統(tǒng)自動分配離客戶最近的車。公司的核心競爭力是讓客戶以最快的速度叫到車。
和公司業(yè)務(wù)人員調(diào)研后，我們把公司業(yè)務(wù)分成三個子域：(用戶/司機）身份認證子領(lǐng)域、打車管理子域及報表子域。
打車管理子域是核心子域，我們以打車管理子域為例提取網(wǎng)上叫車的業(yè)務(wù)術(shù)語。
業(yè)務(wù)規(guī)則：
打車：經(jīng)認證的用戶，打開叫車應(yīng)用，首先會定位，會在地圖上顯示附近的汽車。用戶發(fā)起叫車后，系統(tǒng)會自動通知離客戶最近的司機。用戶到達目的地后，系統(tǒng)自動從用戶關(guān)聯(lián)的賬戶扣款。
分配司機：系統(tǒng)為用戶分配一個最近的司機
計費：系統(tǒng)根據(jù)用戶所乘車的當前位置進行計費
扣款申請：用戶到達目的地后，系統(tǒng)根據(jù)路程的長遠向用戶的銀行賬戶發(fā)送扣款申請
打車管理子域依賴于身份認證子領(lǐng)域。只用經(jīng)過認證的用戶和司機才可以使用打車管理App，只有有足夠信用額度的用戶才可以打車。運營報表依賴于打車管理子領(lǐng)域，運營報表目前僅需要從打車管理里提取用戶的消費記錄，后面估計還會有其它需求。
角色和對象：
以打車管理限界上下文，分析參與者
在打車管理限界上下文里，有兩個明顯的角色：用戶和司機
用戶：在打車App有有效的賬號，有足夠的信用，叫車時要有精確的位置
司機：需要在打車App上注冊的，有有效的身份證明和駕駛證，無不良記錄。收到用戶的訂單后，將用戶從起始點安全地送到目的地。
細致分析后，我們發(fā)現(xiàn)還有一個隱式的對象：訂單。從業(yè)務(wù)來看，最終的目的還是為了多拿訂單，從這個角度來看，訂單是比比用戶和司機都重要的業(yè)務(wù)對象。
業(yè)務(wù)狀態(tài)：
以打車管理限界上下文，分析業(yè)務(wù)狀態(tài)
用戶已叫車、用戶已上車、用戶已到達
身份認證限界上下文、打車管理限界上下文、運營報表限界上下文
聚合：
訂單：是業(yè)務(wù)的真正關(guān)注點。訂單的根實體是訂單本身、本次計費總額，值對象為用戶的路途（起始位置、終止位置），關(guān)聯(lián)的實體包括用戶和司機。
用戶：對于用戶，在打車管理這個限界上下文里，我們只關(guān)注用戶的ID、銀行賬戶。根實體是用戶，關(guān)聯(lián)實體是銀行賬戶，包括賬號、銀行名稱。用戶會發(fā)起叫車的事件。
司機:在打車管理限界上下文里，我們關(guān)注的是司機的id，車牌號及司機當前位置。司機當前位置為值對象。用戶上車后，司機會發(fā)出用戶已上車的信號。到達終點時，司機會發(fā)起已到達的事件
領(lǐng)域服務(wù)：
用戶定位服務(wù)：用戶打開打車App時，會自動啟動定位服務(wù)，并顯示周圍的司機
分配司機服務(wù)：收到用戶叫車的消息后，為用戶分配一個最近的司機
計費管理服務(wù)：用戶上車后，會實時搜集司機當前位置，并實時計費。當收到已到達終點的信號時，自動向用戶管理賬號發(fā)起扣款申請。
領(lǐng)域事件：
用戶已叫車事件：由用戶發(fā)起
用戶已上車事件：由司機發(fā)起
用戶已到達事件：由司機發(fā)起
微服務(wù)里的微并不是越小越好。微服務(wù)和分布式架構(gòu)是相關(guān)聯(lián)的。分布式架構(gòu)第一原則是能不做分布式就不要分布式，對于微服務(wù)，是在能滿足業(yè)務(wù)需求的情況下，盡可能的不微。所以，對于新的需求，微服務(wù)的粒度可以和限界上下文一對一映射。當需求逐漸明晰了后，如果業(yè)務(wù)需要，微服務(wù)的最小粒度可以放到聚合的級別。
因為是創(chuàng)業(yè)公司，對很對需求了解都還不夠細，我們微服務(wù)粒度和限界上下文對應(yīng)，現(xiàn)有的版本是V1.0
定義訂單資源庫類OrderRepository。OrderReporsitory接口目前定義一種方法：findByUserID，返回和該ID相關(guān)聯(lián)的用戶的所有訂單
OrderRepository基于Repository接口。在Repository接口里定義三種方法：add、remove、update。用來增加、刪除、更新訂單
DDD并不是一個新的架構(gòu)方法，它在微服務(wù)概念提出之前就已經(jīng)出現(xiàn)了。微服務(wù)概念提出后，大家都認為很好，但是對于如何設(shè)計微服務(wù)當時沒有給出一個很好的方法，后來，大家套用了DDD的理念來設(shè)計微服務(wù)，發(fā)現(xiàn)這種方法是可行的，DDD的很多理念也和微服務(wù)是一致的。
本文中的舉例，對業(yè)務(wù)的理解不一定到位，我也相信會有更好的模型，領(lǐng)域事件的設(shè)計也偷懶了，請大家多多指教。
下一節(jié)，我們會基于目前的設(shè)計，利用Spring Cloud框架開發(fā)叫車管理微服務(wù)。
聯(lián)系客服
