• 用一個(gè)項(xiàng)目來了解 DDD 的戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)，走一遍從領(lǐng)域建模到微服務(wù)設(shè)計(jì)的全過程，一起掌握 DDD 的主要設(shè)計(jì)流程和關(guān)鍵
  點(diǎn)。

項(xiàng)目基本信息

• 項(xiàng)目的目標(biāo)是實(shí)現(xiàn)在線請假和考勤管理。功能描述如下：
  1. 請假人填寫請假單提交審批，根據(jù)請假人身份、請假類型和請假天數(shù)進(jìn)行校驗(yàn)，根據(jù)審批規(guī)則逐級遞交上級審批，逐級核批通過則完成審批，否則審批不通過退回申請人。
  2. 根據(jù)考勤規(guī)則，核銷請假數(shù)據(jù)后，對考勤數(shù)據(jù)進(jìn)行校驗(yàn)，輸出考勤統(tǒng)計(jì)。

戰(zhàn)略設(shè)計(jì)

• 戰(zhàn)略設(shè)計(jì)是根據(jù)用戶旅程分析，找出領(lǐng)域?qū)ο蠛途酆细?#xff0c;對實(shí)體和值對象進(jìn)行聚類組成聚合，劃分限界上下文，建立領(lǐng)域模型的過程。
• 戰(zhàn)略設(shè)計(jì)采用的方法是事件風(fēng)暴，包括：產(chǎn)品愿景、場景分析、領(lǐng)域建模和微服務(wù)拆分等幾個(gè)主要過程。
• 戰(zhàn)略設(shè)計(jì)階段建議參與人員：領(lǐng)域?qū)＜?、業(yè)務(wù)需求方、產(chǎn)品經(jīng)理、架構(gòu)師、項(xiàng)目經(jīng)理、開發(fā)經(jīng)理和測試經(jīng)理。

1. 產(chǎn)品愿景

• 產(chǎn)品愿景是對產(chǎn)品頂層價(jià)值設(shè)計(jì)，對產(chǎn)品目標(biāo)用戶、核心價(jià)值、差異化競爭點(diǎn)等信息達(dá)成一致，避免產(chǎn)品偏離方向。
• 事件風(fēng)暴時(shí)，所有參與者針對每一個(gè)要點(diǎn)，在貼紙上寫出自己的意見，貼到白板上。事件風(fēng)暴主持者會(huì)對每個(gè)貼紙，討論并對發(fā)散的意見進(jìn)行收斂和統(tǒng)一，形成下面的產(chǎn)品愿景圖。
  
• 我們把這個(gè)產(chǎn)品愿景圖整理成一段文字就是：為了滿足內(nèi)外部人員，他們的在線請假、自動(dòng)考勤統(tǒng)計(jì)和外部人員管理的需求，我們建設(shè)這個(gè)在線請假考勤系統(tǒng)，它是一個(gè)在線請假平臺(tái)，可以自動(dòng)考勤統(tǒng)計(jì)。它可以同時(shí)支持內(nèi)外網(wǎng)請假，同時(shí)管理內(nèi)外部人員請假和定期考勤分析，而不像 HR 系統(tǒng)，只管理內(nèi)部人員，且只能內(nèi)網(wǎng)使用。我們的產(chǎn)品內(nèi)外網(wǎng)皆可使用，可實(shí)現(xiàn)內(nèi)外部人員無差異管理。
• 通過產(chǎn)品愿景分析，項(xiàng)目團(tuán)隊(duì)統(tǒng)一了系統(tǒng)名稱——在線請假考勤系統(tǒng)，明確了項(xiàng)目目標(biāo)和關(guān)鍵功能，與競品（HR）的關(guān)鍵差異以及自己的優(yōu)勢和核心競爭力等。
• 產(chǎn)品愿景分析對于初創(chuàng)系統(tǒng)明確系統(tǒng)建設(shè)重點(diǎn)，統(tǒng)一團(tuán)隊(duì)建設(shè)目標(biāo)和建立通用語言是很有價(jià)值的。但如果你的系統(tǒng)目標(biāo)和需求非常清晰，這一步可以忽略。

2. 場景分析

• 場景分析是從用戶視角出發(fā)，探索業(yè)務(wù)領(lǐng)域中的典型場景，產(chǎn)出領(lǐng)域中需要支撐的場景分類、用例操作以及不同子域之間的依賴關(guān)系，用以支撐領(lǐng)域建模。
• 項(xiàng)目團(tuán)隊(duì)成員一起用事件風(fēng)暴分析請假和考勤的用戶旅程。根據(jù)不同角色的旅程和場景分析，盡可能全面地梳理從前端操作到后端業(yè)務(wù)邏輯發(fā)生的所有操作、命令、領(lǐng)域事件以及外部依賴關(guān)系等信息。
• 以請假和人員兩個(gè)場景作為示例。
  • 場景：請假
  • 用戶：請假人
    • 請假人登錄系統(tǒng)：從權(quán)限微服務(wù)獲取請假人信息和權(quán)限數(shù)據(jù)，完成登錄認(rèn)證。
    • 創(chuàng)建請假單：打開請假頁面，選擇請假類型和起始時(shí)間，錄入請假信息。保存并創(chuàng)建請假單，提交請假審批。
    • 修改請假單：查詢請假單，打開請假頁面，修改請假單，提交請假審批。
    • 提交審批：獲取審批規(guī)則，根據(jù)審批規(guī)則，從人員組織關(guān)系中獲取審批人，給請假單分配審批人。
  • 第二個(gè)場景：審批
  • 用戶：審批人
    • 審批人登錄系統(tǒng)：從權(quán)限微服務(wù)獲取審批人信息和權(quán)限數(shù)據(jù)，完成登錄認(rèn)證。
    • 獲取請假單：獲取審批人名下請假單，選擇請假單。
    • 審批：填寫審批意見。
    • 逐級審批：如果還需要上級審批，根據(jù)審批規(guī)則，從人員組織關(guān)系中獲取審批人，給請假單分配審批人。重復(fù)以上 4 步。
    • 最后審批人完成審批。
• 完成審批后，產(chǎn)生請假審批已通過領(lǐng)域事件。后續(xù)有兩個(gè)進(jìn)一步的業(yè)務(wù)操作：發(fā)送請假審批已通過的通知，通知郵件系統(tǒng)告知請假人；將請假數(shù)據(jù)發(fā)送到考勤以便核銷。

• 下面這個(gè)圖是人員組織關(guān)系場景分析結(jié)果圖，詳細(xì)的分析過程以及考勤的場景分析就不描述了。

3. 領(lǐng)域建模

• 領(lǐng)域建模是通過對業(yè)務(wù)和問題域進(jìn)行分析，建立領(lǐng)域模型。向上通過限界上下文指導(dǎo)微服務(wù)邊界設(shè)計(jì)，向下通過聚合指導(dǎo)實(shí)體對象設(shè)計(jì)。

領(lǐng)域建模是一個(gè)收斂的過程，分三步：

• 第一步找出領(lǐng)域?qū)嶓w和值對象等領(lǐng)域?qū)ο?#xff1b;
  • 根據(jù)場景分析，分析并找出發(fā)起或產(chǎn)生這些命令或領(lǐng)域事件的實(shí)體和值對象。將與實(shí)體或值對象有關(guān)的命令和事件聚集到實(shí)體。
  • 下面這個(gè)圖是分析后的實(shí)體與命令的關(guān)系。通過分析，我們找到了：請假單、審批意見、審批規(guī)則、人員、組織關(guān)系、刷卡明細(xì)、考勤明細(xì)以及考勤統(tǒng)計(jì)等實(shí)體和值對象。
    
• 第二步找出聚合根，根據(jù)實(shí)體、值對象與聚合根的依賴關(guān)系，建立聚合；
  • 定義聚合前，先找出聚合根。從上面的實(shí)體中，我們可以找出“請假單”和“人員”兩個(gè)聚合根。然后找出與聚合根緊密依賴的實(shí)體和值對象。我們發(fā)現(xiàn)審批意見、審批規(guī)則和請假單緊密關(guān)聯(lián)，組織關(guān)系和人員緊密關(guān)聯(lián)。
  • 找出這些實(shí)體的關(guān)系后，我們發(fā)現(xiàn)還有刷卡明細(xì)、考勤明細(xì)和考勤統(tǒng)計(jì)，這幾個(gè)實(shí)體沒有聚合根。這種情形在領(lǐng)域建模時(shí)你會(huì)經(jīng)常遇到，對于這類場景我們需要分情況特殊處理。刷卡明細(xì)、考勤明細(xì)和考勤統(tǒng)計(jì)這幾個(gè)實(shí)體，它們之間相互獨(dú)立，找不出聚合根，不是富領(lǐng)域模型，但它們一起完成考勤業(yè)務(wù)邏輯，具有很高的業(yè)務(wù)內(nèi)聚性。我們將這幾個(gè)業(yè)務(wù)關(guān)聯(lián)緊密的實(shí)體，放在一個(gè)考勤聚合內(nèi)。在微服務(wù)設(shè)計(jì)時(shí)，我們依然采用 DDD 的設(shè)計(jì)和分析方法。由于沒有聚合根來管理聚合內(nèi)的實(shí)體，我們可以用傳統(tǒng)的方法來管理實(shí)體。
  • 經(jīng)過分析，我們建立了請假、人員組織關(guān)系和考勤三個(gè)聚合。其中請假聚合有請假單、審批意見實(shí)體和審批規(guī)則等值對象。人員組織關(guān)系聚合有人員和組織關(guān)系等實(shí)體?？记诰酆嫌兴⒖骷?xì)、考勤明細(xì)和考勤統(tǒng)計(jì)等實(shí)體。
    
• 第三步根據(jù)業(yè)務(wù)及語義邊界等因素，定義限界上下文。
  • 由于人員組織關(guān)系聚合與請假聚合，共同完成請假的業(yè)務(wù)功能，兩者在請假的限界上下文內(nèi)?？记诰酆蟿t單獨(dú)構(gòu)成考勤統(tǒng)計(jì)限界上下文。因此我們?yōu)闃I(yè)務(wù)劃分請假和考勤統(tǒng)計(jì)兩個(gè)限界上下文，建立請假和考勤兩個(gè)領(lǐng)域模型。

4. 微服務(wù)的拆分

• 理論上一個(gè)限界上下文就可以設(shè)計(jì)為一個(gè)微服務(wù)，但還需要綜合考慮多種外部因素，比如：職責(zé)單一性、敏態(tài)與穩(wěn)態(tài)業(yè)務(wù)分離、非功能性需求（如彈性伸縮、版本發(fā)布頻率和安全等要求）、軟件包大小、團(tuán)隊(duì)溝通效率和技術(shù)異構(gòu)等非業(yè)務(wù)要素。
• 在這個(gè)項(xiàng)目，我們劃分微服務(wù)主要考慮職責(zé)單一性原則。因此根據(jù)限界上下文就可以拆分為請假和考勤兩個(gè)微服務(wù)。其中請假微服務(wù)包含人員組織關(guān)系和請假兩個(gè)聚合，考勤微服務(wù)包含考勤聚合。
• 到這里，戰(zhàn)略設(shè)計(jì)就結(jié)束了。通過戰(zhàn)略設(shè)計(jì)，我們建立了領(lǐng)域模型，劃分了微服務(wù)邊界。下一步就是戰(zhàn)術(shù)設(shè)計(jì)了，也就是微服務(wù)設(shè)計(jì)。

戰(zhàn)術(shù)設(shè)計(jì)

• 戰(zhàn)術(shù)設(shè)計(jì)是根據(jù)領(lǐng)域模型進(jìn)行微服務(wù)設(shè)計(jì)的過程。這個(gè)階段主要梳理微服務(wù)內(nèi)的領(lǐng)域?qū)ο?#xff0c;梳理領(lǐng)域?qū)ο笾g的關(guān)系，確定它們在代碼模型和分層架構(gòu)中的位置，建立領(lǐng)域模型與微服務(wù)模型的映射關(guān)系，以及服務(wù)之間的依賴關(guān)系。
• 戰(zhàn)術(shù)設(shè)計(jì)階段建議參與人員：領(lǐng)域?qū)＜?、產(chǎn)品經(jīng)理、架構(gòu)師、項(xiàng)目經(jīng)理、開發(fā)經(jīng)理和測試經(jīng)理等。
• 戰(zhàn)術(shù)設(shè)計(jì)包括以下兩個(gè)階段：分析微服務(wù)領(lǐng)域?qū)ο蠛驮O(shè)計(jì)微服務(wù)代碼結(jié)構(gòu)。

1. 分析微服務(wù)領(lǐng)域?qū)ο?/strong>

• 領(lǐng)域模型有很多領(lǐng)域?qū)ο?#xff0c;但是這些對象帶有比較重的業(yè)務(wù)屬性。要完成從領(lǐng)域模型到微服務(wù)的落地，還需要進(jìn)一步的分析和設(shè)計(jì)。在事件風(fēng)暴基礎(chǔ)上，我們進(jìn)一步細(xì)化領(lǐng)域?qū)ο笠约八鼈兊年P(guān)系，補(bǔ)充事件風(fēng)暴可能遺漏的業(yè)務(wù)和技術(shù)細(xì)節(jié)。

• 我們分析微服務(wù)內(nèi)應(yīng)該有哪些服務(wù)？服務(wù)的分層？應(yīng)用服務(wù)由哪些服務(wù)組合和編排完成？領(lǐng)域服務(wù)包括哪些實(shí)體和實(shí)體方法？哪個(gè)實(shí)體是聚合根？實(shí)體有哪些屬性和方法？哪些對象應(yīng)該設(shè)計(jì)為值對象等。

• 服務(wù)的識(shí)別和設(shè)計(jì)

  • 事件風(fēng)暴的命令是外部的一些操作和業(yè)務(wù)行為，也是微服務(wù)對外提供的能力。它往往與微服務(wù)的應(yīng)用服務(wù)或者領(lǐng)域服務(wù)對應(yīng)。我們可以將命令作為服務(wù)識(shí)別和設(shè)計(jì)的起點(diǎn)。具體步驟如下：
    • 根據(jù)命令設(shè)計(jì)應(yīng)用服務(wù)，確定應(yīng)用服務(wù)的功能，服務(wù)集合，組合和編排方式。服務(wù)集合中的服務(wù)包括領(lǐng)域服務(wù)或其它微服務(wù)的應(yīng)用服務(wù)。
    • 根據(jù)應(yīng)用服務(wù)功能要求設(shè)計(jì)領(lǐng)域服務(wù)，定義領(lǐng)域服務(wù)。這里需要注意：應(yīng)用服務(wù)可能是由多個(gè)聚合的領(lǐng)域服務(wù)組合而成的。
    • 根據(jù)領(lǐng)域服務(wù)的功能，確定領(lǐng)域服務(wù)內(nèi)的實(shí)體以及功能。
    • 設(shè)計(jì)實(shí)體基本屬性和方法。

• 另外，我們還要考慮領(lǐng)域事件的異步化處理。以提交審批這個(gè)動(dòng)作為例，來說明服務(wù)的識(shí)別和設(shè)計(jì)。提交審批的大體流程是：

  • 根據(jù)請假類型和時(shí)長，查詢請假審批規(guī)則，獲取下一步審批人的角色。
  • 根據(jù)審批角色從人員組織關(guān)系中查詢下一審批人。
  • 為請假單分配審批人，并將審批規(guī)則保存至請假單。
  • 通過分析，我們需要在應(yīng)用層和領(lǐng)域?qū)釉O(shè)計(jì)以下服務(wù)和方法。

• 應(yīng)用層：提交審批應(yīng)用服務(wù)。

• 領(lǐng)域?qū)?#xff1a;領(lǐng)域服務(wù)有查詢審批規(guī)則、修改請假流程信息服務(wù)以及根據(jù)審批規(guī)則查詢審批人服務(wù)，分別位于請假和人員組織關(guān)系聚合。請假單實(shí)體有修改請假流程信息方法，審批規(guī)則值對象有查詢審批規(guī)則方法。人員實(shí)體有根據(jù)審批規(guī)則查詢審批人方法。下圖是我們分析出來的服務(wù)以及它們之間的依賴關(guān)系。
  

• 聚合中的對象

  • 在請假單聚合中，聚合根是請假單。
  • 請假單經(jīng)多級審核后，會(huì)產(chǎn)生多條審批意見，為了方便查詢，我們可以將審批意見設(shè)計(jì)為實(shí)體。請假審批通過后，會(huì)產(chǎn)生請假審批通過的領(lǐng)域事件，因此還會(huì)有請假事件實(shí)體。請假聚合有以下實(shí)體：審批意見（記錄審批人、審批狀態(tài)和審批意見）和請假事件實(shí)體。
  • 我們再來分析一下請假單聚合的值對象。請假人和下一審批人數(shù)據(jù)來源于人員組織關(guān)系聚合中的人員實(shí)體，可設(shè)計(jì)為值對象。人員類型、請假類型和審批狀態(tài)是枚舉值類型，可設(shè)計(jì)為值對象。確定請假審批規(guī)則后，審批規(guī)則也可作為請假單的值對象。請假單聚合將包含以下值對象：請假人、人員類型、請假類型、下一審批人、審批狀態(tài)和審批規(guī)則。
  • 綜上，我們就可以畫出請假聚合對象關(guān)系圖了。
    
  • 在人員組織關(guān)系聚合中，我們可以建立人員之間的組織關(guān)系，通過組織關(guān)系類型找到上級審批領(lǐng)導(dǎo)。它的聚合根是人員。實(shí)體有組織關(guān)系（包括組織關(guān)系類型和上級審批領(lǐng)導(dǎo)）。其中組織關(guān)系類型（如項(xiàng)目經(jīng)理、處長、總經(jīng)理等）是值對象。上級審批領(lǐng)導(dǎo)來源于人員聚合根，可設(shè)計(jì)為值對象。人員組織關(guān)系聚合將包含以下值對象：組織關(guān)系類型、上級審批領(lǐng)導(dǎo)。
  • 綜上，我們又可以畫出人員組織關(guān)系聚合對象關(guān)系圖了。
    

• 微服務(wù)內(nèi)的對象清單：在確定各領(lǐng)域?qū)ο蟮膶傩院?#xff0c;我們就可以設(shè)計(jì)各領(lǐng)域?qū)ο笤诖a模型中的代碼對象（包括代碼對象的包名、類名和方法名），建立領(lǐng)域?qū)ο笈c代碼對象的一一映射關(guān)系了。根據(jù)這種映射關(guān)系，相關(guān)人員可快速定位到業(yè)務(wù)邏輯所在的代碼位置。在經(jīng)過以上分析后，我們在微服務(wù)內(nèi)就可以分析出如下圖的對象清單。
  

2. 設(shè)計(jì)微服務(wù)代碼結(jié)構(gòu)

• 根據(jù) DDD 的代碼模型和各領(lǐng)域?qū)ο笏诘陌㈩惡头椒?#xff0c;我們可以定義出請假微服務(wù)的代碼結(jié)構(gòu)，設(shè)計(jì)代碼對象。
• 應(yīng)用層代碼結(jié)構(gòu)
  • 應(yīng)用層包括：應(yīng)用服務(wù)、DTO 以及事件發(fā)布相關(guān)代碼。在 LeaveApplicationService 類內(nèi)實(shí)現(xiàn)與聚合相關(guān)的應(yīng)用服務(wù)，在 LoginApplicationService 封裝外部微服務(wù)認(rèn)證和權(quán)限的應(yīng)用服務(wù)。如果應(yīng)用服務(wù)邏輯復(fù)雜的話，一個(gè)應(yīng)用服務(wù)就可以構(gòu)建一個(gè)類，這樣可以避免一個(gè)類的代碼過于龐大，不利于維護(hù)。
    
  • 領(lǐng)域?qū)哟a結(jié)構(gòu)：領(lǐng)域?qū)影ㄒ粋€(gè)或多個(gè)聚合的實(shí)體類、事件實(shí)體類、領(lǐng)域服務(wù)以及工廠、倉儲(chǔ)相關(guān)代碼。一個(gè)聚合對應(yīng)一個(gè)聚合代碼目錄，聚合之間在代碼上完全隔離，聚合之間通過應(yīng)用層協(xié)調(diào)。請假微服務(wù)領(lǐng)域?qū)影埣俸腿藛T兩個(gè)聚合。人員和請假代碼都放在各自的聚合所在目錄結(jié)構(gòu)的代碼包中。如果隨著業(yè)務(wù)發(fā)展，人員相關(guān)功能需要從請假微服務(wù)中拆分出來，我們只需將人員聚合代碼包稍加改造，獨(dú)立部署，即可快速發(fā)布為人員微服務(wù)。到這里，微服務(wù)內(nèi)的領(lǐng)域?qū)ο?#xff0c;分層以及依賴關(guān)系就梳理清晰了。微服務(wù)的總體架構(gòu)和代碼模型也基本搭建完成了。
    

后續(xù)的工作

1. 詳細(xì)設(shè)計(jì)

• 在完成領(lǐng)域模型和微服務(wù)設(shè)計(jì)后，我們還需要對微服務(wù)進(jìn)行詳細(xì)的設(shè)計(jì)。主要設(shè)計(jì)以下內(nèi)容：實(shí)體屬性、數(shù)據(jù)庫表和字段、實(shí)體與數(shù)據(jù)庫表映射、服務(wù)參數(shù)規(guī)約及功能實(shí)現(xiàn)等。

2. 代碼開發(fā)和測試

• 開發(fā)人員只需要按照詳細(xì)的設(shè)計(jì)文檔和功能要求，找到業(yè)務(wù)功能對應(yīng)的代碼位置，完成代碼開發(fā)就可以了。代碼開發(fā)完成后，開發(fā)人員要編寫單元測試用例，基于擋板模擬依賴對象完成服務(wù)測試。

你知道的越多，你不知道的越多。