17 | 從後端到前端：微服務後，前端如何設計？
課程鏈接：https://time.geekbang.org/column/article/169017
微服務架構通常採用前後端分離的設計方式。作爲企業級的中臺，在完成單體應用拆分和微服務建設後，前端項目團隊會同時面對多箇中臺微服務項目團隊，這時候的前端人員就猶如維修電工一樣了。
面對如此多的微服務暴露出來的 API 服務，如何進行正確的連接和拼裝，才能保證不出錯？這顯然不是一件很容易的事情。而當服務出現變更時，又如何通知所有受影響的項目團隊，這裏面的溝通成本相信也不小。
相應的，要從一定程度上解決上述問題，是不是可以考慮先有效降低前端集成的複雜度呢？先做到前端聚合，後端解耦——這是一個很有意思的話題。一起來聊聊微前端（Micro Frontend）的設計思想，探討一下中臺微服務後，前後端的設計和集成方式。
單體前端的困境
傳統企業在完成中臺轉型後，雖然後臺的業務完成了微服務架構的升級，但前端仍然是單體模式，由一個團隊創建並維護一個前端應用。隨着時間推移和業務發展，前端會變得越來越臃腫，越來越難維護。而隨着 5G 和移動互聯技術的應用，企業業務活動將會進一步移動化和線上化。過去很多企業的做法是爲不同的業務開發出獨立的 APP。但很顯然用戶並不想裝那麼多的 APP！
爲了提高用戶體驗，實現統一運營，很多企業開始縮減和整合 APP，將企業內所有的業務能力都儘量集中到一個 APP 中。試想如果仍然沿用單體前端的設計模式。前端項目團隊將面對多箇中臺微服務團隊，需要集成成千上萬的 API 服務，這就需要相當高的溝通成本和技術要求。這絕對會是一場災難。
相對互聯網企業而言，傳統企業的渠道應用更加多樣化，有面向內部人員的門店類應用、面向外部客戶的互聯網電商平臺或移動 APP，還有面向第三方的 API 集成。由於渠道的差異，前端將更加多樣化和複雜化。那如何有效降低前端集成的複雜度呢？
從單體前端到微前端
爲了解決單體前端的問題，可以借鑑微服務的設計思想，引入微前端概念。將微服務理念擴展到前端，解決中臺微服務化後，前端由於仍爲單體而存在的邏輯複雜和臃腫的問題。
在前端設計時需要遵循單一職責和複用原則，按照領域模型和微服務邊界，將前端頁面進行拆分。同時構建多個可以獨立部署、完全自治、松耦合的頁面組合，其中每個組合只負責特定業務單元的 UI 元素和功能，這些頁面組合就是微前端。
微前端與微服務一樣，都是希望將單體應用，按照規則拆分，並重組爲多個可以獨立開發、獨立測試、獨立部署和獨立運維，松耦合的微前端或者微服務。以適應業務快速變化及分佈式多團隊並行開發的要求。
微前端頁面只包括業務單元前端操作必需的頁面要素，它只是企業級完整業務流程中的一個業務拼圖塊，不包含頁面導航等內容。微前端除了可以實現前端頁面的解耦外，還可實現頁面複用，這也與中臺服務共享理念是一脈相承的。
業務單元的組合形態
可以參照領域模型和微服務邊界，建立與微服務對應的前端操作界面，將它與微服務組成業務單元，以業務組件的方式對外提供服務。業務單元包括微前端和微服務，可以獨立開發、測試、部署和運維，可以自包含地完成領域模型中部分或全部的業務功能。
看一下下面這個圖。一個虛框就是一個業務單元，微前端和微服務獨立部署，業務單元內的微前端和微服務已完成前後端集成。可以將這個業務單元理解爲一個特定業務領域的組件。業務單元可以有多種組合方式，以實現不同的業務目標。
1. 單一業務單元
一個微前端和一個微服務組成單一業務單元。微前端和微服務分別實現同一個領域模型從前端到後端的功能。
2. 組合業務單元
一個微前端與多個微服務組成組合業務單元。微前端具有多個微服務的前端功能，完成較複雜的頁面和操作。多個微服務實現各自領域模型的功能，向微前端提供可組合的服務。記住一點：微前端不宜與過多的微服務組合，否則容易變成單體前端。
3. 通用共享業務單元
一個微前端與一個或多個通用中臺微服務組合爲通用共享業務單元。通用共享微前端以共享頁面的方式與其它微前端頁面協作，完成業務流程。很多通用中臺微服務的微前端是共享的，比如訂單和支付等微服務對應的訂單和支付微前端界面。
所有業務單元的功能都應該自包含，業務單元之間的邊界清晰。業務單元之間要避免功能交叉而出現耦合，一旦出現就會影響項目團隊職責邊界，進而影響到業務單元獨立開發、測試、部署和運維等。
微前端的集成方式
看一下下面這個圖，微前端位於前端主頁面和微服務之間，它需要與兩者完成集成。
1. 微前端與前端主頁面的集成
前端主頁面是企業級的前端頁面，微前端是業務單元的前端頁面。微前端通過主頁面的微前端加載器，利用頁面路由和動態加載等技術，將特定業務單元的微前端頁面動態加載到前端主頁面，實現前端主頁面與微前端頁面的“拼圖式”集成。
微前端完成開發、集成和部署後，在前端主頁面完成微前端註冊以及頁面路由配置，即可實現動態加載微前端頁面。
2. 微前端與微服務的集成
微前端與微服務獨立開發，獨立部署。在微前端註冊到前端主頁面前，微前端需要與微服務完成集成。它的集成方式與傳統前後端分離的集成方式沒有差異。微服務將服務發佈到 API 網關，微前端調用發佈在 API 網關中的服務，即完成業務單元內的前後端集成。
團隊職責邊界
當採用業務單元化的開發方式後，前後端項目團隊職責和應用邊界會更清晰，可以降低前後端集成的複雜度。看一下前中臺團隊的職責分工。
前端項目團隊專注於前端集成主頁面與微前端的集成，完成前端主頁面的企業級主流程的頁面和流程編排以及微前端頁面的動態加載，確保主流程業務邏輯和流程正確。前端項目除了要負責企業內頁面風格的整體風格設計、業務流程的流轉和控制外，還需要負責微前端頁面動態加載、微前端註冊、頁面路由和頁面數據共享等前端技術的實現。
中臺項目團隊完成業務單元組件的開發、測試和集成，確保業務單元內的業務邏輯、頁面和流程正確，向外提供包含頁面邏輯和業務邏輯的業務單元組件。
這樣，前端項目團隊只需要完成企業級前端主頁面與業務單元的融合，前端只關注前端主頁面與微前端頁面之間的集成。這樣就可以降低前端團隊的技術敏感度、團隊的溝通成本和集成複雜度，提高交付效率和用戶體驗。
中臺項目團隊關注業務單元功能的完整性和自包含能力，完成業務單元內微服務和微前端開發、集成和部署，提供業務單元組件。這樣，業務單元的微前端與微服務的集成就會由一箇中臺團隊完成，熟悉的人幹熟悉的事情，可以降低集成過程中的溝通和技術成本，加快開發效率。
一個有關保險微前端設計的案例
保險公司有很多面向不同場景的保險產品，由於業務場景不同，其核心領域模型就會有差異，在頁面要素、業務規則和流程等方面前端界面也會不同。爲了避免領域模型差異較大的產品之間的相互影響和干擾，可以將相似的領域模型的保險產品聚合在一起，完成核心中臺設計。
那有的保險集團爲了統一運營，會實現壽險、財險等集團化的全險種銷售。這樣前端項目團隊就需要用一個前端應用，集成非常多的不同產品的核心中臺微服務，前端應用與中臺微服務之間的集成將會更復雜。
如果仍然採用傳統的單體前端模式，將會面臨比較大的困難。
第一是前端頁面開發和設計的複雜性。以錄單前端爲例，如果用一個前端頁面來適配全險種，由於不同產品的前端頁面要素不同，需要妥協併兼容所有產品界面的差異，這會增加前端開發的複雜度，也影響用戶體驗。而如果爲每類產品開發不同的前端，前端項目團隊需要在頁面開發和設計上，投入巨大的工作量。
第二是前端與微服務集成的複雜性。在前端與微服務集成時，前端項目團隊需要了解所有產品的 API 詳細信息，完成前端與微服務的集成，還要根據主頁面流程，實現不同產品的 API 服務路由。大量的 API 服務集成和服務路由，會增加系統集成的複雜度和出錯的概率。
第三是前後端軟件版本的協同發佈。關聯的應用多了以後，一旦某一箇中臺微服務的 API 服務出現重大調整，就需要協調所有受影響的應用同時完成版本發佈，頻繁的版本發佈會影響不同產品的正常運營。
那如何用一個前端應用實現全險種產品銷售呢？怎樣設計才能降低集成的複雜度，實現前端界面融合，後端中臺解耦呢？
看一下下面這個圖。借鑑了電商的訂單模式實現保險產品的全險種訂單化銷售，在一個前端主頁面可以將所有業務流程和業務操作無縫串聯起來。雖然後端有很多業務單元（包含微服務和微前端），但用戶始終感覺是在一個前端應用中操作。
要在一個前端應用中實現全險種銷售，需要完成以下內容的設計。
1. 微服務：微服務分爲兩類，一類是核心中臺微服務，包括：投保微服務，實現核心出單業務邏輯；另一類是通用中臺微服務，包括如：商品、訂單、購物車和支付等微服務，實現通用共享業務邏輯。
2. 微前端：每個微服務都有自己的微前端頁面，實現領域模型的微服務前端頁面操作。核心中臺投保微服務有出單微前端。訂單、商品以及支付微服務都有自己的微前端頁面。
3. 業務單元：微服務與微前端組合爲一個業務單元。由一箇中臺團隊完成業務單元的開發、集成、測試和部署，確保業務單元內頁面操作和業務邏輯正確。比如：投保微服務和出單微前端組合爲投保業務單元，獨立完成保險產品從前端到後端的投保業務。
4. 前端主頁面：前端主頁面類似門戶，包括頁面導航以及部分通用的常駐主頁面的共享頁面，比如購物車。前端主頁面和所有微前端應統一界面風格，符合統一的前端集成規範。按照正確的業務邏輯和規則，動態加載不同業務單元的微前端頁面。前端主頁面作爲一個整體，協調核心和通用業務單元的微前端頁面，完成業務操作和業務流程，提供全險種銷售接觸界面，包括商品目錄、錄單、購物車、訂單、支付等操作。
5. 業務流程說明：簡要說明一下用戶在前端主頁面的投保的主要業務流程。
- 第 1 步：用戶在前端主頁面，從商品目錄微前端頁面，選擇保險產品。
- 第 2 步：前端主頁面根據選擇的產品，從主頁面配置數據中，獲取產品出單微前端路由地址。加載出單微前端頁面，完成錄單，投保微服務實現投保業務邏輯，在業務單元內生成投保單。
- 第 3 步：加載購物車微前端，將投保單加入購物車。
- 第 4 步：重複 1-3 步，生成多個投保單。
- 第 5 步：從購物車微前端中選擇多個投保單，加載訂單微前端，生成訂單。
- 第 6 步：加載支付微前端，完成支付。
- 第 7 步：在投保微服務中，將訂單中的投保單生成保單。
雖然後端有很多業務單元在支持，但用戶所有的頁面操作和流轉是在一個前端主頁面完成的。在進行全險種的訂單化銷售時，用戶始終感覺是在操作一個系統。這種設計方式很好地體現了前端的融合和中臺的解耦。
總結
微前端和業務單元化的設計模式可以減輕企業級中臺，前後端應用開發和集成的複雜度，真正實現前端融合和中臺解耦。它的主要價值和意義如下：
1. 前端集成簡單：前端項目只需關注前端集成主頁面與微前端的集成，實現模塊化集成和拼圖式的開發，降低前端集成的複雜度和成本。
2. 項目職責專一：中臺項目從數據庫、中臺微服務到微前端界面，端到端地完成領域邏輯功能開發，以業務組件的方式整體提供服務。在業務單元內，由團隊自己完成前後端集成，可以降低開發和集成團隊的溝通成本和集成複雜度。
3. 隔離和依賴性：業務單元在代碼、邏輯和物理邊界都是隔離的，可降低應用之間的依賴性。出現問題時可快速定位和修復，問題可以控制在一個業務單元內。業務單元之間相互無影響。
4. 降低溝通和測試成本：中臺團隊實現從微前端頁面到中臺微服務的業務單元邏輯，實現業務單元的開發、測試、集成和部署的全流程和全生命週期管理，降低前後端集成的測試和溝通成本。
5. 更敏捷地發佈：業務單元之間有很好的隔離性和依賴性低，業務單元的變化都可以被控制在業務單元內。項目團隊可以獨立按照自己的步調進行迭代開發，實現更快的發佈週期。版本發佈時不會影響其它業務單元的正常運行。
6. 降低技術敏感性：前端項目關注前端主頁面與微前端的集成。降低了前端項目團隊對中臺微服務技術的敏感性。中臺項目團隊可以更獨立地嘗試新技術和架構，實現架構的演進。
7. 高度複用性：微前端和中臺微服務都有高度的複用性。微前端可快速加載到多個 APP，還可以將一個微前端直接發佈爲 APP 或微信小程序，實現靈活的前端組合、複用和快速發佈。
======================================================================================================
18 | 知識點串講：基於DDD的微服務設計實例
課程鏈接：https://time.geekbang.org/column/article/169881
從領域建模到微服務設計的全過程
項目基本信息
項目的目標是實現在線請假和考勤管理。功能描述如下：
1.請假人填寫請假單提交審批，根據請假人身份、請假類型和請假天數進行校驗，根據審批規則逐級遞交上級審批，逐級覈批通過則完成審批，否則審批不通過退回申請人。
2.根據考勤規則，覈銷請假數據後，對考勤數據進行校驗，輸出考勤統計。
戰略設計
戰略設計是根據用戶旅程分析，找出領域對象和聚合根，對實體和值對象進行聚類組成聚合，劃分限界上下文，建立領域模型的過程。
戰略設計採用的方法是事件風暴，包括：產品願景、場景分析、領域建模和微服務拆分等幾個主要過程。
戰略設計階段建議參與人員：領域專家、業務需求方、產品經理、架構師、項目經理、開發經理和測試經理。
1. 產品願景
產品願景是對產品頂層價值設計，對產品目標用戶、核心價值、差異化競爭點等信息達成一致，避免產品偏離方向。
事件風暴時，所有參與者針對每一個要點，在貼紙上寫出自己的意見，貼到白板上。事件風暴主持者會對每個貼紙，討論並對發散的意見進行收斂和統一，形成下面的產品願景圖。
把這個產品願景圖整理成一段文字就是：爲了滿足內外部人員，他們的在線請假、自動考勤統計和外部人員管理的需求，建設這個在線請假考勤系統，它是一個在線請假平臺，可以自動考勤統計。它可以同時支持內外網請假，同時管理內外部人員請假和定期考勤分析，而不像 HR 系統，只管理內部人員，且只能內網使用。產品內外網皆可使用，可實現內外部人員無差異管理。
通過產品願景分析，項目團隊統一了系統名稱——在線請假考勤系統，明確了項目目標和關鍵功能，與競品（HR）的關鍵差異以及自己的優勢和核心競爭力等。
產品願景分析對於初創系統明確系統建設重點，統一團隊建設目標和建立通用語言是很有價值的。但如果系統目標和需求非常清晰，這一步可以忽略。
2. 場景分析
場景分析是從用戶視角出發，探索業務領域中的典型場景，產出領域中需要支撐的場景分類、用例操作以及不同子域之間的依賴關係，用以支撐領域建模。
項目團隊成員一起用事件風暴分析請假和考勤的用戶旅程。根據不同角色的旅程和場景分析，儘可能全面地梳理從前端操作到後端業務邏輯發生的所有操作、命令、領域事件以及外部依賴關係等信息。
下面以請假和人員兩個場景作爲示例。
第一個場景：請假
用戶：請假人
- 請假人登錄系統：從權限微服務獲取請假人信息和權限數據，完成登錄認證。
- 創建請假單：打開請假頁面，選擇請假類型和起始時間，錄入請假信息。保存並創建請假單，提交請假審批。
- 修改請假單：查詢請假單，打開請假頁面，修改請假單，提交請假審批。
- 提交審批：獲取審批規則，根據審批規則，從人員組織關係中獲取審批人，給請假單分配審批人。
第二個場景：審批
用戶：審批人
- 審批人登錄系統：從權限微服務獲取審批人信息和權限數據，完成登錄認證。
- 獲取請假單：獲取審批人名下請假單，選擇請假單。
- 審批：填寫審批意見。
- 逐級審批：如果還需要上級審批，根據審批規則，從人員組織關係中獲取審批人，給請假單分配審批人。重複以上 4 步。
- 最後審批人完成審批。
完成審批後，產生請假審批已通過領域事件。後續有兩個進一步的業務操作：發送請假審批已通過的通知，通知郵件系統告知請假人；將請假數據發送到考勤以便覈銷。
下面這個圖是人員組織關係場景分析結果圖，詳細的分析過程以及考勤的場景分析就不描述了。
3. 領域建模
領域建模是通過對業務和問題域進行分析，建立領域模型。向上通過限界上下文指導微服務邊界設計，向下通過聚合指導實體對象設計。領域建模是一個收斂的過程，分三步：
- 第一步找出領域實體和值對象等領域對象；
- 第二步找出聚合根，根據實體、值對象與聚合根的依賴關係，建立聚合；
- 第三步根據業務及語義邊界等因素，定義限界上下文。
下面逐步詳細講解一下。
第一步：找出實體和值對象等領域對象
根據場景分析，分析並找出發起或產生這些命令或領域事件的實體和值對象，將與實體或值對象有關的命令和事件聚集到實體。
下面這個圖是分析後的實體與命令的關係。通過分析，找到了：請假單、審批意見、審批規則、人員、組織關係、刷卡明細、考勤明細以及考勤統計等實體和值對象。
第二步：定義聚合
定義聚合前，先找出聚合根。從上面的實體中，可以找出“請假單”和“人員”兩個聚合根。然後找出與聚合根緊密依賴的實體和值對象。發現審批意見、審批規則和請假單緊密關聯，組織關係和人員緊密關聯。
找出這些實體的關係後，發現還有刷卡明細、考勤明細和考勤統計，這幾個實體沒有聚合根。這種情形在領域建模時會經常遇到，對於這類場景需要分情況特殊處理。
刷卡明細、考勤明細和考勤統計這幾個實體，它們之間相互獨立，找不出聚合根，不是富領域模型，但它們一起完成考勤業務邏輯，具有很高的業務內聚性。將這幾個業務關聯緊密的實體，放在一個考勤聚合內。在微服務設計時，依然採用 DDD 的設計和分析方法。由於沒有聚合根來管理聚合內的實體，可以用傳統的方法來管理實體。
經過分析，建立了請假、人員組織關係和考勤三個聚合。其中請假聚合有請假單、審批意見實體和審批規則等值對象。人員組織關係聚合有人員和組織關係等實體。考勤聚合有刷卡明細、考勤明細和考勤統計等實體。
第三步：定義限界上下文
由於人員組織關係聚合與請假聚合，共同完成請假的業務功能，兩者在請假的限界上下文內。考勤聚合則單獨構成考勤統計限界上下文。因此爲業務劃分請假和考勤統計兩個限界上下文，建立請假和考勤兩個領域模型。
4. 微服務的拆分
理論上一個限界上下文就可以設計爲一個微服務，但還需要綜合考慮多種外部因素，比如：職責單一性、敏態與穩態業務分離、非功能性需求（如彈性伸縮、版本發佈頻率和安全等要求）、軟件包大小、團隊溝通效率和技術異構等非業務要素。
在這個項目，劃分微服務主要考慮職責單一性原則。因此根據限界上下文就可以拆分爲請假和考勤兩個微服務。其中請假微服務包含人員組織關係和請假兩個聚合，考勤微服務包含考勤聚合。
到這裏，戰略設計就結束了。通過戰略設計，建立了領域模型，劃分了微服務邊界。下一步就是戰術設計了，也就是微服務設計。下面以請假微服務爲例，講解其設計過程。
戰術設計
戰術設計是根據領域模型進行微服務設計的過程。這個階段主要梳理微服務內的領域對象，梳理領域對象之間的關係，確定它們在代碼模型和分層架構中的位置，建立領域模型與微服務模型的映射關係，以及服務之間的依賴關係。
戰術設計階段建議參與人員：領域專家、產品經理、架構師、項目經理、開發經理和測試經理等。
戰術設計包括以下兩個階段：分析微服務領域對象和設計微服務代碼結構。
1. 分析微服務領域對象
領域模型有很多領域對象，但是這些對象帶有比較重的業務屬性。要完成從領域模型到微服務的落地，還需要進一步的分析和設計。在事件風暴基礎上，進一步細化領域對象以及它們的關係，補充事件風暴可能遺漏的業務和技術細節。
分析微服務內應該有哪些服務？服務的分層？應用服務由哪些服務組合和編排完成？領域服務包括哪些實體和實體方法？哪個實體是聚合根？實體有哪些屬性和方法？哪些對象應該設計爲值對象等。
服務的識別和設計
事件風暴的命令是外部的一些操作和業務行爲，也是微服務對外提供的能力。它往往與微服務的應用服務或者領域服務對應。可以將命令作爲服務識別和設計的起點。具體步驟如下：
- 根據命令設計應用服務，確定應用服務的功能，服務集合，組合和編排方式。服務集合中的服務包括領域服務或其它微服務的應用服務。
- 根據應用服務功能要求設計領域服務，定義領域服務。這裏需要注意：應用服務可能是由多個聚合的領域服務組合而成的。
- 根據領域服務的功能，確定領域服務內的實體以及功能。
- 設計實體基本屬性和方法。
另外，還要考慮領域事件的異步化處理。
提交審批這個動作爲例，來說明服務的識別和設計。提交審批的大體流程是：
- 根據請假類型和時長，查詢請假審批規則，獲取下一步審批人的角色。
- 根據審批角色從人員組織關係中查詢下一審批人。
- 爲請假單分配審批人，並將審批規則保存至請假單。
- 通過分析，需要在應用層和領域層設計以下服務和方法。
應用層：提交審批應用服務。
領域層：領域服務有查詢審批規則、修改請假流程信息服務以及根據審批規則查詢審批人服務，分別位於請假和人員組織關係聚合。請假單實體有修改請假流程信息方法，審批規則值對象有查詢審批規則方法。人員實體有根據審批規則查詢審批人方法。下圖是分析出來的服務以及它們之間的依賴關係。
服務的識別和設計過程就是這樣了，再來設計一下聚合內的對象。
聚合中的對象
在請假單聚合中，聚合根是請假單。
請假單經多級審覈後，會產生多條審批意見，爲了方便查詢，可以將審批意見設計爲實體。請假審批通過後，會產生請假審批通過的領域事件，因此還會有請假事件實體。請假聚合有以下實體：審批意見（記錄審批人、審批狀態和審批意見）和請假事件實體。再來分析一下請假單聚合的值對象。請假人和下一審批人數據來源於人員組織關係聚合中的人員實體，可設計爲值對象。人員類型、請假類型和審批狀態是枚舉值類型，可設計爲值對象。確定請假審批規則後，審批規則也可作爲請假單的值對象。請假單聚合將包含以下值對象：請假人、人員類型、請假類型、下一審批人、審批狀態和審批規則。
綜上，就可以畫出請假聚合對象關係圖了。
在人員組織關係聚合中，可以建立人員之間的組織關係，通過組織關係類型找到上級審批領導。它的聚合根是人員，實體有組織關係（包括組織關係類型和上級審批領導），其中組織關係類型（如項目經理、處長、總經理等）是值對象。上級審批領導來源於人員聚合根，可設計爲值對象。人員組織關係聚合將包含以下值對象：組織關係類型、上級審批領導。
綜上，又可以畫出人員組織關係聚合對象關係圖了。
微服務內的對象清單
在確定各領域對象的屬性後，就可以設計各領域對象在代碼模型中的代碼對象（包括代碼對象的包名、類名和方法名），建立領域對象與代碼對象的一一映射關係了。根據這種映射關係，相關人員可快速定位到業務邏輯所在的代碼位置。在經過以上分析後，在微服務內就可以分析出如下圖的對象清單。
2. 設計微服務代碼結構
根據 DDD 的代碼模型和各領域對象所在的包、類和方法，可以定義出請假微服務的代碼結構，設計代碼對象。
應用層代碼結構
應用層包括：應用服務、DTO 以及事件發佈相關代碼。在 LeaveApplicationService 類內實現與聚合相關的應用服務，在 LoginApplicationService 封裝外部微服務認證和權限的應用服務。
這裏提醒一下：如果應用服務邏輯複雜的話，一個應用服務就可以構建一個類，這樣可以避免一個類的代碼過於龐大，不利於維護。
領域層代碼結構
領域層包括一個或多個聚合的實體類、事件實體類、領域服務以及工廠、倉儲相關代碼。一個聚合對應一個聚合代碼目錄，聚合之間在代碼上完全隔離，聚合之間通過應用層協調。
請假微服務領域層包含請假和人員兩個聚合。人員和請假代碼都放在各自的聚合所在目錄結構的代碼包中。如果隨着業務發展，人員相關功能需要從請假微服務中拆分出來，只需將人員聚合代碼包稍加改造，獨立部署，即可快速發佈爲人員微服務。到這裏，微服務內的領域對象，分層以及依賴關係就梳理清晰了。微服務的總體架構和代碼模型也基本搭建完成了。
後續的工作
1. 詳細設計
在完成領域模型和微服務設計後，還需要對微服務進行詳細的設計。主要設計以下內容：實體屬性、數據庫表和字段、實體與數據庫表映射、服務參數規約及功能實現等。
2. 代碼開發和測試
開發人員只需要按照詳細的設計文檔和功能要求，找到業務功能對應的代碼位置，完成代碼開發就可以了。代碼開發完成後，開發人員要編寫單元測試用例，基於擋板模擬依賴對象完成服務測試。