緒論

傳統(tǒng)數(shù)字化轉(zhuǎn)型需要解決的幾個問題

1.技術(shù)體系落后

可擴(kuò)展能力不強(qiáng)谒亦，高可用能力不強(qiáng)，面對突發(fā)高頻訪問的業(yè)務(wù)場景羡微，不能實(shí)現(xiàn)自動彈性伸縮傻唾，發(fā)展到一定規(guī)模后投慈，數(shù)據(jù)庫性能和容量成為業(yè)務(wù)發(fā)展的瓶頸。

2.單體架構(gòu)問題

將很多功能放到一個應(yīng)用中，日積月累伪煤，這個應(yīng)用編程一個龐大的怪物加袋，隨著人員的更替，時間一長很少人能完全搞懂這些代碼的邏輯關(guān)系带族。一些人擔(dān)心遺留代碼锁荔，不敢修改之前的代碼蟀给，寧愿復(fù)制一份代碼出來重新修改蝙砌，導(dǎo)致應(yīng)用越來越復(fù)雜，最終陷入惡性循環(huán)跋理。單體也存在模塊耦合度高择克，彈性擴(kuò)容資源利用不高。

3.研發(fā)和運(yùn)維能力落后的問題

云平臺和自動化運(yùn)維工具對單體應(yīng)用的生態(tài)支撐有限前普，部署和運(yùn)維相對復(fù)雜肚邢，應(yīng)用出現(xiàn)問題基本靠人肉排查，運(yùn)維和研發(fā)難以快速定位拭卿。

4.IT能力重復(fù)建設(shè)問題

傳統(tǒng)企業(yè)已經(jīng)建立了一套單體核心系統(tǒng)骡湖，為了在移動互聯(lián)網(wǎng)開拓業(yè)務(wù)，又建立了一套移動互聯(lián)網(wǎng)應(yīng)用峻厚，出現(xiàn)了一些業(yè)務(wù)同質(zhì)化問題响蕴。為了解決這個問題就需要提升技術(shù)能力和重構(gòu)業(yè)務(wù)模型入手，實(shí)現(xiàn)企業(yè)級業(yè)務(wù)的能力復(fù)用惠桃。

微服務(wù)雖好浦夷，但它只是手段不是目的，微服務(wù)是為了解決業(yè)務(wù)和應(yīng)用擴(kuò)展能力辜王，也是了更好上云劈狐。微服務(wù)實(shí)施需要一定的前置條件。技術(shù)能力提升了呐馆，傳統(tǒng)應(yīng)用和移動應(yīng)用才有統(tǒng)一的基礎(chǔ)肥缔；應(yīng)用統(tǒng)一了，才會有業(yè)務(wù)模型的統(tǒng)一汹来；業(yè)務(wù)模型統(tǒng)一了辫继，才能實(shí)現(xiàn)業(yè)務(wù)能力共享和復(fù)用，企業(yè)才會有實(shí)施中臺戰(zhàn)略的技術(shù)基礎(chǔ)俗慈。

為什么會面臨單體架構(gòu)問題姑宽？
1.團(tuán)隊(duì)小的時候，單體的開發(fā)效率最高
2.當(dāng)時團(tuán)隊(duì)技術(shù)能力不足闺阱，研發(fā)人員不夠重視
3.服務(wù)器經(jīng)費(fèi)不足
4.業(yè)務(wù)發(fā)展不允許炮车，業(yè)務(wù)上需要快速的實(shí)現(xiàn)功能，沒有過多的時間去設(shè)計系統(tǒng)的擴(kuò)展性和高可用等。
所以單體架構(gòu)可能是很多團(tuán)隊(duì)不得不面臨的一個問題瘦穆，當(dāng)企業(yè)發(fā)展后纪隙，單體向微服務(wù)的遷移也是一個不得不面臨的問題。

認(rèn)識中臺
ThoughtWorks對中臺的定義：“中臺是企業(yè)級能力復(fù)用平臺”扛或。中臺本質(zhì)上是企業(yè)的業(yè)務(wù)模型绵咱。中臺如何落地，微服務(wù)架構(gòu)是目前公認(rèn)的最佳實(shí)踐熙兔，中臺落地時會面臨微服務(wù)應(yīng)該如何拆分和設(shè)計的問題悲伶。是否有好的方法來指導(dǎo)微服務(wù)的拆分和設(shè)計呢？那就是DDD(領(lǐng)域驅(qū)動設(shè)計)住涉，DDD包含戰(zhàn)略設(shè)計和戰(zhàn)術(shù)設(shè)計兩個階段麸锉，通過戰(zhàn)略設(shè)計完成中臺業(yè)務(wù)邊界劃分和領(lǐng)域建模，然后將領(lǐng)域模型作為戰(zhàn)術(shù)設(shè)計的輸入舆声，完成微服務(wù)設(shè)計花沉。

阿里對前臺、中臺媳握、后臺職責(zé)的定位碱屁，前臺主要面向客戶以及終端銷售者，實(shí)現(xiàn)營銷推廣以及交易轉(zhuǎn)換蛾找。中臺主要面向運(yùn)營人員娩脾，完成運(yùn)營支撐。后臺主要面向后臺管理人員腋粥，實(shí)現(xiàn)流程審核晦雨、內(nèi)部管理、后勤支撐隘冲，比如采購闹瞧、人力、財務(wù)展辞、OA等系統(tǒng)奥邮。企業(yè)級能力往往是前臺、中臺罗珍、后臺協(xié)作能力的體現(xiàn)洽腺，如果把業(yè)務(wù)中臺比作陸軍、火箭軍覆旱、空軍等專業(yè)軍種蘸朋，主要發(fā)揮單一軍種的戰(zhàn)術(shù)專業(yè)能力，那么前臺就是作戰(zhàn)部隊(duì)扣唱，它會根據(jù)前線戰(zhàn)場的實(shí)時作戰(zhàn)需求藕坯，快速完成不同職能業(yè)務(wù)中臺能力的組合和調(diào)度团南，實(shí)現(xiàn)不同業(yè)務(wù)板塊能力的融合，形成強(qiáng)大的組合打擊能力完成精確打擊炼彪，獲得最大企業(yè)效能吐根。而數(shù)據(jù)中臺就是信息情報中心和聯(lián)合作戰(zhàn)總指揮，是企業(yè)智能化的大腦辐马，它能夠匯聚各類一線作戰(zhàn)板塊的數(shù)據(jù)和信息完成數(shù)據(jù)分析拷橘，制定戰(zhàn)略和戰(zhàn)術(shù)計劃，完成不同業(yè)務(wù)中臺能力的智能調(diào)度和組合喜爷，為前臺作戰(zhàn)部隊(duì)提供快速數(shù)據(jù)和情報服務(wù)忿等。后臺就是后勤部隊(duì)莉兰，主要提供企業(yè)后端支持和管理能力大咱。

中臺能力總體框架

image.png

戰(zhàn)術(shù)設(shè)計則是從技術(shù)視角出發(fā)俩由，側(cè)重于對領(lǐng)域模型的技術(shù)實(shí)現(xiàn)，按照領(lǐng)域模型完成微服務(wù)的開發(fā)和落地癌蚁。在戰(zhàn)術(shù)設(shè)計上會有聚合幻梯、聚合根、實(shí)體努释、值對象碘梢、領(lǐng)域服務(wù)、領(lǐng)域時間伐蒂、應(yīng)用服務(wù)煞躬、倉儲等領(lǐng)域?qū)ο螅@些領(lǐng)域?qū)ο髸源a的形式映射到微服務(wù)中逸邦，完成設(shè)計和系統(tǒng)落地恩沛。

image.png

DDD戰(zhàn)略設(shè)計中的領(lǐng)域建模是一個從發(fā)散到收斂的過程，通常采用事件風(fēng)暴工作法缕减。事件風(fēng)暴是一項(xiàng)團(tuán)隊(duì)活動雷客，領(lǐng)域?qū)＜遗c項(xiàng)目團(tuán)隊(duì)通過頭腦風(fēng)暴的形式，羅列出領(lǐng)域中所有的領(lǐng)域事件桥狡，然后為每一個事件標(biāo)注出導(dǎo)致該事件的命令搅裙，再為每一個事件標(biāo)注出命令發(fā)起方的角色

基于事件風(fēng)暴的領(lǐng)域建模的關(guān)鍵過程包括：產(chǎn)品愿景分析（可選）妓局、場景分析、領(lǐng)域建模呈宇、微服務(wù)拆分與設(shè)計這幾個重要階段好爬。原則上，一個界限上下文內(nèi)的領(lǐng)域模型就可以設(shè)計為一個微服務(wù)甥啄，但領(lǐng)域建模時存炮，只考慮了業(yè)務(wù)因素，并沒有考慮微服務(wù)落地的技術(shù)蜈漓、團(tuán)隊(duì)穆桂、運(yùn)行環(huán)境等非業(yè)務(wù)因素，因此它只能作為微服務(wù)拆分的一個非常重要的依據(jù)融虽，而不是唯一依據(jù)享完。構(gòu)建邊界清晰的領(lǐng)域模型，才是我們的最關(guān)鍵目標(biāo)有额。

DDD的核心目的是為“高內(nèi)聚般又，低耦合”提供一個可行辦法。

DDD巍佑、中臺茴迁、微服務(wù)的關(guān)系

image.png

image.png

image.png

子域和界限上下文的關(guān)系？大多數(shù)情況下是一對一或一對多的映射關(guān)系椿争。有時候業(yè)務(wù)領(lǐng)域非常龐大怕膛，不太方便使用時間風(fēng)暴對整個領(lǐng)域構(gòu)建領(lǐng)域模型，所以在領(lǐng)域建模前丘薛，我們先根據(jù)業(yè)務(wù)流程邊界或功能集合等要素嘉竟，將龐大領(lǐng)域分解為若干個合適的子域，然后在根據(jù)屬性劃分為核心子域洋侨、通用子域舍扰、支撐子域，然后再對這些子域內(nèi)開展事件風(fēng)暴希坚，劃分界限上下文

實(shí)體和值對象
在代碼模型中边苹，實(shí)體的表現(xiàn)形式是實(shí)體類，這個類包含了實(shí)體的屬性和方法裁僧，通過這些方法實(shí)現(xiàn)實(shí)體自身的業(yè)務(wù)行為和業(yè)務(wù)邏輯个束，這些實(shí)體通常采用充血模型慕购，跨多個實(shí)體的領(lǐng)域邏輯則在領(lǐng)域服務(wù)中實(shí)現(xiàn)。貧血模型中領(lǐng)域?qū)ο蟠蠖嘀挥衧etter和getter方法茬底，業(yè)務(wù)邏輯統(tǒng)一放在業(yè)務(wù)邏輯層實(shí)現(xiàn)沪悲，而不是領(lǐng)域?qū)ο笾袑?shí)現(xiàn)。

實(shí)體以領(lǐng)域?qū)ο螅―O）的形式存在阱表，每個實(shí)體對象都有唯一的ID殿如，我們可以對一個實(shí)體對象多次修改，修改后的實(shí)體數(shù)據(jù)和原來的數(shù)據(jù)可能會不大相同最爬，但是由于擁有相同的ID涉馁，他們?nèi)匀皇且粋€實(shí)體。比如商品是商品界限上下文的一個實(shí)體爱致，通過唯一的商品ID來標(biāo)示烤送。不管這個商品的數(shù)據(jù)如何變化，商品的ID一直保持不變糠悯，所以它始終是同一個商品帮坚。

實(shí)體的數(shù)據(jù)庫形態(tài)，與傳統(tǒng)數(shù)據(jù)庫模型設(shè)計優(yōu)先不同逢防，DDD是先構(gòu)建領(lǐng)域模型叶沛，通過場景分析找出實(shí)體對象和行為蒲讯，再將實(shí)體對象映射到數(shù)據(jù)持久對象忘朝。一個實(shí)體可以對應(yīng)0個、1個或多個數(shù)據(jù)庫持久化對象判帮。如何解決一對多或多對一場景局嘁？

值對象本質(zhì)是個屬性集合，是不可變的晦墙，它沒有ID悦昵，它只是有數(shù)據(jù)初始化操作和有限的不涉及修改數(shù)據(jù)的行為，基本不包含業(yè)務(wù)邏輯晌畅。

聚合與聚合根

實(shí)體和值對象都是個體化的業(yè)務(wù)對象但指，他們表現(xiàn)出來的是個體的行為和能力。在領(lǐng)域模型中抗楔，我們需要一個這樣的組織棋凳，將這些緊密關(guān)聯(lián)的個體對象聚集在一起，按照組織內(nèi)統(tǒng)一的業(yè)務(wù)規(guī)則共同完成特定的業(yè)務(wù)功能连躏，因此就有了聚合的概念剩岳。聚合內(nèi)數(shù)據(jù)的修改必須由聚合根統(tǒng)一組織，以確保每次數(shù)據(jù)修改都是按照聚合內(nèi)統(tǒng)一的業(yè)務(wù)規(guī)則來完成入热。過去拍棕，在傳統(tǒng)數(shù)據(jù)模型中每個實(shí)體都是對等的晓铆，在業(yè)務(wù)邏輯實(shí)現(xiàn)時，可以隨意找到實(shí)體或數(shù)據(jù)庫表完成數(shù)據(jù)修改绰播，但這類操作在DDD的聚合內(nèi)是不被允許的骄噪。

調(diào)用關(guān)系：

聚合內(nèi)的實(shí)體以充血模型實(shí)現(xiàn)自身的業(yè)務(wù)邏輯
跨多個實(shí)體的業(yè)務(wù)邏輯通過領(lǐng)域服務(wù)實(shí)現(xiàn)
跨多個聚合的業(yè)務(wù)邏輯的組合和編排，是通過應(yīng)用服務(wù)來實(shí)現(xiàn)的
判斷一個實(shí)體是否是聚合根蠢箩？
是否有獨(dú)立的生命周期
是否有全局唯一ID
是否可以創(chuàng)建或修改其他對象
是否有專門的模塊來管理這個實(shí)體
怎么理解聚合根管理功能腰池？

聚合設(shè)計原則

聚合是拆分微服務(wù)最小業(yè)務(wù)單元
設(shè)計小聚合
通過唯一ID引用其他聚合
在邊界之外使用最終一致性。在聚合內(nèi)采用數(shù)據(jù)強(qiáng)一致性忙芒，在聚合之間采用數(shù)據(jù)最終一致性示弓。這時因?yàn)镈DD強(qiáng)調(diào)子一次事務(wù)中，最多只能修改一個聚合的數(shù)據(jù)呵萨。如果涉及多個聚合數(shù)據(jù)修改奏属，那么應(yīng)采用領(lǐng)域事件驅(qū)動機(jī)制。怎么理解邊界之外潮峦？是界限上下文囱皿？還是理解成聚合？
通過應(yīng)用層實(shí)現(xiàn)跨聚合的服務(wù)調(diào)用忱嘹。
聚合根在聚合內(nèi)對實(shí)體和值對象通過對象引用的方式進(jìn)行組織和協(xié)調(diào)嘱腥，聚合與聚合之間只能通過聚合根ID引用的方式，實(shí)現(xiàn)聚合之間的訪問和協(xié)同拘悦。
倉儲模式就是用來隔離業(yè)務(wù)實(shí)現(xiàn)邏輯與基礎(chǔ)層資源實(shí)現(xiàn)邏輯齿兔，降低它們之間的耦合和相互影響而產(chǎn)生的。
倉庫模式包含倉儲接口和倉儲實(shí)現(xiàn)础米，倉儲接口面向領(lǐng)域?qū)犹峁┗A(chǔ)層數(shù)據(jù)處理相關(guān)的訪問接口分苇，倉儲實(shí)現(xiàn)完成倉儲接口對應(yīng)的數(shù)據(jù)持久化相關(guān)的邏輯處理。

領(lǐng)域事件：解耦微服務(wù)的關(guān)鍵

image.png

到底是將領(lǐng)域事件直接發(fā)布到時間總線屁桑、消息中間件医寿、或者通過CDC再轉(zhuǎn)發(fā)到消息中間件，可根據(jù)業(yè)務(wù)場景選擇
因?yàn)殛P(guān)鍵數(shù)據(jù)不能丟失或者需要數(shù)據(jù)對賬蘑斧，所以事件發(fā)布之前需要持久化到數(shù)據(jù)庫事件表中靖秩。

DDD分層架構(gòu)

image.png

微服務(wù)目錄結(jié)構(gòu)

image.png

<meta charset="utf-8">

interfaces目錄下面有assembler、dto竖瘾、facade

assembler實(shí)現(xiàn)DTO和DO領(lǐng)域?qū)ο笾g的相互轉(zhuǎn)換和數(shù)據(jù)交換沟突，同dto同時出現(xiàn)
dto是前端應(yīng)用數(shù)據(jù)傳輸?shù)妮d體，前端需要的數(shù)據(jù)格式或前端傳輸過來的數(shù)據(jù)格式准浴。
facade封裝應(yīng)用服務(wù)事扭，將用戶請求委派到一個或多個應(yīng)用服務(wù)進(jìn)行處理。
application目錄有event乐横、service
event主要是publish和subscribe
service是應(yīng)用服務(wù)求橄，

對于多表關(guān)聯(lián)的復(fù)雜查詢今野，由于這種復(fù)雜查詢不需要有領(lǐng)域邏輯和業(yè)務(wù)規(guī)則約束，因此不建議將這類復(fù)雜查詢放在領(lǐng)域?qū)拥念I(lǐng)域模型中罐农，可以通過應(yīng)用層的應(yīng)用服務(wù)采用傳統(tǒng)多表關(guān)聯(lián)的SQL查詢方式条霜，也可以采用CQRS讀寫分離方式完成數(shù)據(jù)查詢操作。

為了實(shí)現(xiàn)微服務(wù)內(nèi)聚合的解耦涵亏，原則上我們應(yīng)該盡量避免聚合之間的領(lǐng)域服務(wù)直接調(diào)用和聚合之間的數(shù)據(jù)庫表關(guān)聯(lián)宰睡。聚合之間的服務(wù)調(diào)用和數(shù)據(jù)交互，可通過應(yīng)用服務(wù)完成气筋。

domian目錄下面的leave拆内、person、rule都是聚合

領(lǐng)域事件訂閱建議放到應(yīng)用層event,領(lǐng)域事件發(fā)布相關(guān)代碼放到領(lǐng)域?qū)雍蛻?yīng)用層都是可以的

工廠類（factory）放到領(lǐng)域?qū)泳酆系膕ervice目錄下宠默，倉儲相關(guān)代碼放到領(lǐng)域?qū)泳酆系膔epository目錄結(jié)構(gòu)下

案例地址：https://github.com/ouchuangxin/leave-sample.git

下圖為各領(lǐng)域?qū)ο笤诟鲗游恢煤驼{(diào)用關(guān)系

image.png

作者：lodestar
鏈接：http://www.reibang.com/p/5049f4f851fb
來源：簡書
著作權(quán)歸作者所有麸恍。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處搀矫。