零售財(cái)務(wù)中臺架構(gòu)設(shè)計(jì)與實(shí)踐

1、零售財(cái)務(wù)中臺架構(gòu)設(shè)計(jì)與實(shí)踐一、背景傳統(tǒng)模式下，企業(yè)的經(jīng)營活動會產(chǎn)生大量的業(yè)務(wù)數(shù)據(jù)。財(cái)務(wù)人員需要根據(jù)業(yè)務(wù)數(shù)據(jù)，進(jìn)行會計(jì)核算，并輸出財(cái)務(wù)數(shù)據(jù)。通過這些財(cái)務(wù)數(shù)據(jù)，企業(yè)可以進(jìn)行財(cái)務(wù)管理、財(cái)務(wù)分析、業(yè)務(wù)決策。但會計(jì)核算的工作量非常龐大，大多工作也比較基礎(chǔ)、簡單，可以被計(jì)算機(jī)替代。企業(yè)每年在基礎(chǔ)的核算工作上會花費(fèi)大量的人力資源，在更重要的財(cái)務(wù)管理、財(cái)務(wù)分析、業(yè)務(wù)決策上無暇顧及。為了解決此類問題，財(cái)務(wù)中臺應(yīng)運(yùn)而生。財(cái)務(wù)中臺是業(yè)務(wù)系統(tǒng)和財(cái)務(wù)總賬系統(tǒng)間的橋梁，通過匯集所有業(yè)務(wù)數(shù)據(jù)，進(jìn)行篩選、核算、轉(zhuǎn)換，自動生成財(cái)務(wù)數(shù)據(jù)，并傳入財(cái)務(wù)總賬系統(tǒng)，節(jié)省大量會計(jì)核算的人工成本。除此之外，財(cái)務(wù)人員不需要在各個業(yè)務(wù)系統(tǒng)間來回

2、切換，核對業(yè)務(wù)數(shù)據(jù)。財(cái)務(wù)中臺匯聚了所有財(cái)務(wù)數(shù)據(jù)，財(cái)務(wù)人員可以在統(tǒng)一的工作臺上進(jìn)行數(shù)據(jù)核對和會計(jì)工作，不需要跨多個系統(tǒng)操作。通過財(cái)務(wù)中臺，可以輕松實(shí)現(xiàn)業(yè)財(cái)一體化，財(cái)務(wù)人員可以解放生產(chǎn)力，產(chǎn)出更高的價(jià)值。二、財(cái)務(wù)中臺業(yè)務(wù)架構(gòu)2.1 零售整體業(yè)務(wù)架構(gòu)零售整體業(yè)務(wù)架構(gòu)分為前臺業(yè)務(wù)、總部中臺、企業(yè)/業(yè)務(wù)后臺。前臺業(yè)務(wù)的特點(diǎn)是變化快、差異性大、細(xì)節(jié)體驗(yàn)、跨平臺、多觸點(diǎn)。前臺業(yè)務(wù)幫助商家整合盡可能多的零售渠道進(jìn)行銷售，以滿足顧客購物、娛樂和社交的綜合體驗(yàn)需求?？偛恐信_從架構(gòu)上是串聯(lián)前臺業(yè)務(wù)和后臺業(yè)務(wù)，基于零售商家的核心經(jīng)營場景，建立會員、交易、營銷、運(yùn)營、財(cái)務(wù)、數(shù)據(jù)等核心功能?？偛恐信_并不直接為商家和消費(fèi)者

3、提供應(yīng)用服務(wù)，它的主要職責(zé)是匯總所有業(yè)務(wù)數(shù)據(jù)，協(xié)同各個業(yè)務(wù)單元，提煉業(yè)務(wù)的共性需求，支撐前、后臺業(yè)務(wù)的快速發(fā)展。通過總部中臺，商家可以跟蹤和積累消費(fèi)者的購物全渠道、全過程的數(shù)據(jù)，在這個過程中與消費(fèi)者及時互動，掌握消費(fèi)者在購買過程中的決策變化，給消費(fèi)者個性化建議，提升購物體驗(yàn)。再依靠大數(shù)據(jù)，對用戶做到精準(zhǔn)營銷、智能推薦商品；智能化采購更適合銷售的產(chǎn)品；做好財(cái)務(wù)管理，持續(xù)提升資金利用效率。企業(yè)/業(yè)務(wù)后臺包括采購要貨、供應(yīng)鏈、原材料管控、生產(chǎn)制造、合同管理、加盟代理、財(cái)務(wù)總賬等基礎(chǔ)業(yè)務(wù)。部分業(yè)務(wù)可能由商家的 ERP 系統(tǒng)完成，所以總部中臺和 ERP 系統(tǒng)會做好數(shù)據(jù)對接，商家的 ERP 系統(tǒng)仍然可以繼

4、續(xù)使用。財(cái)務(wù)中臺屬于總部中臺的一部分，財(cái)務(wù)中臺通過匯集所有業(yè)務(wù)數(shù)據(jù)，進(jìn)行篩選、核算、轉(zhuǎn)換，自動生成財(cái)務(wù)數(shù)據(jù)。同時，財(cái)務(wù)中臺提煉出財(cái)務(wù)相關(guān)的共性-服務(wù)，支撐前、后臺業(yè)務(wù)的快速發(fā)展，幫助商家做好財(cái)務(wù)管理、財(cái)務(wù)分析和業(yè)務(wù)決策。2.2 財(cái)務(wù)中臺業(yè)務(wù)架構(gòu)財(cái)務(wù)中臺匯集全渠道銷售、供應(yīng)鏈、資產(chǎn)、營銷推廣等數(shù)據(jù)，自動完成會計(jì)核算，生成相應(yīng)的財(cái)務(wù)數(shù)據(jù)。同時，財(cái)務(wù)中臺可以進(jìn)一步對接企業(yè)的財(cái)務(wù)總賬；為其他系統(tǒng)集成提供標(biāo)準(zhǔn)化的開放能力；為合作伙伴提供費(fèi)用對賬等服務(wù)；為數(shù)據(jù)報(bào)表提供原始數(shù)據(jù)，加工出財(cái)務(wù)報(bào)表，為財(cái)務(wù)分析、業(yè)務(wù)決策提供有力的支持。三、財(cái)務(wù)中臺應(yīng)用架構(gòu)3.1 什么是應(yīng)用架構(gòu)？應(yīng)用架構(gòu)定義了系統(tǒng)由哪些邏輯模塊組

5、成，以及邏輯模塊之間的關(guān)系，也稱之為邏輯架構(gòu)圖。應(yīng)用架構(gòu)起到承上啟下的作用，一方面承接業(yè)務(wù)架構(gòu)的落地，一方面影響技術(shù)選型。3.2 如何設(shè)計(jì)應(yīng)用架構(gòu)？設(shè)計(jì)應(yīng)用架構(gòu)，首先要明確設(shè)計(jì)的粒度和層次，在不同粒度和層次，關(guān)注點(diǎn)是不一樣的。零售業(yè)務(wù)異常復(fù)雜，對于這種復(fù)雜業(yè)務(wù)，尤其要從宏觀到微觀逐層進(jìn)行詳細(xì)的分析和設(shè)計(jì)，保證整體架構(gòu)的有序性和一致性。如果不這樣做，很容易讓產(chǎn)品技術(shù)團(tuán)隊(duì)陷入混亂中，進(jìn)而極大降低團(tuán)隊(duì)的溝通和協(xié)作效率。這里可以結(jié)合 Simon Brown 提出的 C4 模型來考慮設(shè)計(jì)元素的粒度和層次。自上而下，Simon Brown 將整個軟件系統(tǒng)分為了四個層次，分別為系統(tǒng)上下文（System Co

6、ntext）、容器（Containers）、組件（Components）以及類（Classes），這些層次的說明如下所示。系統(tǒng)上下文：是最高的抽象層次，代表了能夠提供業(yè)務(wù)價(jià)值的構(gòu)件。一個系統(tǒng)由多個獨(dú)立的容器構(gòu)成。容器：是指一個在其內(nèi)部可以執(zhí)行組件或駐留數(shù)據(jù)的構(gòu)件。作為整個系統(tǒng)的一部分，容器通常是可執(zhí)行文件，但未必是各自獨(dú)立的進(jìn)程。組件：可以想象成一個或多個類組成的邏輯群組。組件通常由多個類在更高層次的約束下組合而成。類：在一個面向?qū)ο蟮氖澜缋?，類是軟件系統(tǒng)的最小結(jié)構(gòu)單元。3.3 財(cái)務(wù)中臺應(yīng)用架構(gòu)設(shè)計(jì)那么，財(cái)務(wù)中臺系統(tǒng)在上述四個層次分別該如何設(shè)計(jì)？3.3.1 系統(tǒng)上下文層次設(shè)計(jì)首先是系統(tǒng)上下文層

7、次，該層次會重點(diǎn)關(guān)注要設(shè)計(jì)的系統(tǒng)和其他系統(tǒng)之間的關(guān)系。財(cái)務(wù)中臺系統(tǒng)上下文的設(shè)計(jì)如下圖所示。3.3.2 容器層次設(shè)計(jì)其次是容器層次，該層次會將整個系統(tǒng)放大，關(guān)注系統(tǒng)內(nèi)部由哪些容器構(gòu)成，容器基本等同于限界上下文的概念。限界上下文的劃分是 DDD 戰(zhàn)略設(shè)計(jì)中的一部分，而且是最核心的設(shè)計(jì)工作，需要在該層次識別出限界上下文，這會對后續(xù)微服務(wù)架構(gòu)落地起到關(guān)鍵性作用。上圖為財(cái)務(wù)中臺系統(tǒng)內(nèi)應(yīng)用架構(gòu)圖，采用分層架構(gòu)模式，圖里的應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層和DDD中的概念一致，但它們是容器層次下的分層邏輯，視角是整個系統(tǒng)內(nèi)。對于單體系統(tǒng)來說，應(yīng)用層和領(lǐng)域?qū)舆壿嫊容^簡單，通常會合并為一個微服務(wù)部署，內(nèi)部也不會有非常

8、清晰的限界上下文劃分。但對于企業(yè)級系統(tǒng)，業(yè)務(wù)邏輯非常復(fù)雜，內(nèi)部會劃分出眾多職責(zé)單一、功能完整的限界上下文，以保證系統(tǒng)架構(gòu)健康、有序地進(jìn)行演進(jìn)。應(yīng)用層：應(yīng)用層是很薄的一層，應(yīng)用層內(nèi)的服務(wù)對應(yīng)一個具有業(yè)務(wù)價(jià)值的業(yè)務(wù)用例。它主要負(fù)責(zé)對領(lǐng)域服務(wù)進(jìn)行組合和編排，負(fù)責(zé)處理業(yè)務(wù)用例內(nèi)的執(zhí)行順序以及結(jié)果的組裝，通過API 網(wǎng)關(guān)向接入層提供服務(wù)。容器級應(yīng)用層涉及整個系統(tǒng)的邏輯，通常包含多個廉價(jià)的限界上下文，它們的內(nèi)部業(yè)務(wù)邏輯不會很復(fù)雜，但因?yàn)橹苯用嫦蛴脩?，為了?yīng)對快速變化的外部需求，應(yīng)用層變動會非常頻繁，它通過領(lǐng)域服務(wù)的組合和編排實(shí)現(xiàn)業(yè)務(wù)流程的快速適配上線。例如：上圖所示的結(jié)算管理是一個應(yīng)用層限界上下文，它為接

9、入層提供與結(jié)算管理相關(guān)的應(yīng)用服務(wù)，它通過組合、編排領(lǐng)域?qū)拥暮怂阌?、結(jié)算域、收付域以及其他業(yè)務(wù)系統(tǒng)的領(lǐng)域服務(wù)，來實(shí)現(xiàn)自身應(yīng)用服務(wù)能力。領(lǐng)域?qū)樱侯I(lǐng)域?qū)邮呛芎竦囊粚?，它是業(yè)務(wù)軟件的核心所在，包含了本領(lǐng)域所涉及的領(lǐng)域?qū)ο?、領(lǐng)域服務(wù)以及它們之間的關(guān)系，負(fù)責(zé)表達(dá)業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)信息以及業(yè)務(wù)規(guī)則。領(lǐng)域驅(qū)動設(shè)計(jì)提倡富領(lǐng)域模型，即盡量將業(yè)務(wù)邏輯歸屬到領(lǐng)域?qū)ο笊?，?shí)在無法歸屬的部分則以領(lǐng)域服務(wù)的形式進(jìn)行定義。用戶的需求經(jīng)常變化，但變化總是有規(guī)律的，用戶體驗(yàn)、操作習(xí)慣、市場環(huán)境以及管理流程的變化，往往會導(dǎo)致界面邏輯、應(yīng)用邏輯變化，但核心領(lǐng)域邏輯不會有太大變化，所以領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯通常是共性的、穩(wěn)定的。容器級領(lǐng)域?qū)?/p>

10、涉及整個系統(tǒng)的邏輯，通常包含多個限界上下文，它們?yōu)檎w系統(tǒng)的微服務(wù)拆分提供依據(jù)?；A(chǔ)設(shè)施層：它向其他層提供通用的技術(shù)能力，例如：分布式通信能力、持久化能力、消息通信能力、任務(wù)調(diào)度能力等。3.3.3 組件層次設(shè)計(jì)再次是組件層次，該層次會將單個容器放大，組件是由一個或多個類組成的邏輯組，共同完成一類職責(zé)。在該層次會關(guān)注容器內(nèi)部是如何分層的，每層包含哪些邏輯組件。上圖為應(yīng)用層容器架構(gòu)，同樣采用分層架構(gòu)，包含接口層、應(yīng)用層、防腐層、基礎(chǔ)設(shè)施層。接口層定義了提供給上層使用的服務(wù)協(xié)議（API），接口層的使用方通常是展現(xiàn)層。這里的應(yīng)用層是更細(xì)粒度的、容器內(nèi)的層次，或者說是戰(zhàn)-術(shù)級別的層次，根據(jù)復(fù)雜度不同，它

11、通常包含一到多個限界上下文的應(yīng)用服務(wù)和業(yè)務(wù)組件，每個應(yīng)用服務(wù)通過編排其他限界上下文的服務(wù)，實(shí)現(xiàn)業(yè)務(wù)場景或業(yè)務(wù)用例。防腐層用于和其他限界上下文集成，在防腐層內(nèi)部，你可以將自己的模型和外部模型進(jìn)行轉(zhuǎn)換，防止受外部模型污染，進(jìn)而讓內(nèi)部邏輯不穩(wěn)定。當(dāng)外部模型或接口協(xié)議發(fā)生變化時，只需要修改防腐層邏輯，不會影響到自身業(yè)務(wù)邏輯。應(yīng)用層容器內(nèi)通常沒有領(lǐng)域模型，因此也不需要訪問數(shù)據(jù)庫，因?yàn)樗鼉?nèi)部主要是組合、編排的邏輯，如果出現(xiàn)類似領(lǐng)域模型的概念，要分析是不是有部分領(lǐng)域邏輯外泄到應(yīng)用層，并考慮將領(lǐng)域邏輯下沉到領(lǐng)域?qū)?，以保證應(yīng)用層的職責(zé)統(tǒng)一。上圖為領(lǐng)域?qū)尤萜骷軜?gòu)，分為接口層、應(yīng)用層、領(lǐng)域?qū)?、防腐層、基礎(chǔ)設(shè)施層。接

12、口層定義了提供給上層使用的服務(wù)協(xié)議（API），接口層的使用方通常是應(yīng)用層容器。應(yīng)用層通過編排領(lǐng)域?qū)拥念I(lǐng)域服務(wù)、領(lǐng)域模型以及少量外部服務(wù)來對外提供服務(wù)能力，這里強(qiáng)調(diào)少量的外部服務(wù)，是因?yàn)轭I(lǐng)域?qū)尤萜鲀?nèi)部的業(yè)務(wù)邏輯通常是共性的、穩(wěn)定的，它只會依賴比它更基礎(chǔ)、更穩(wěn)定的服務(wù)能力，而且依賴外部服務(wù)要盡可能少，這樣才能保證容器內(nèi)部的業(yè)務(wù)邏輯是共性的、穩(wěn)定的。這里的領(lǐng)域?qū)邮歉?xì)粒度的、容器內(nèi)的層次，或者說是戰(zhàn)-術(shù)級別的層次。領(lǐng)域?qū)影鞣N領(lǐng)域模型，例如：領(lǐng)域?qū)嶓w、聚合根、領(lǐng)域服務(wù)、倉儲等。倉儲作為領(lǐng)域?qū)雍突A(chǔ)設(shè)施層的連接組件，使得領(lǐng)域?qū)硬槐剡^多的關(guān)注存儲細(xì)節(jié)。在設(shè)計(jì)時，將倉儲接口放在領(lǐng)域?qū)?，而將倉儲的具體實(shí)現(xiàn)

13、放在基礎(chǔ)設(shè)施層，領(lǐng)域?qū)油ㄟ^接口訪問數(shù)據(jù)存儲，而不必過多的關(guān)注倉儲存儲數(shù)據(jù)的細(xì)節(jié)，這樣使得領(lǐng)域?qū)訉⒏嗟年P(guān)注點(diǎn)放在領(lǐng)域邏輯上面。領(lǐng)域?qū)尤萜骷軜?gòu)最核心的是領(lǐng)域?qū)樱诵牡臉I(yè)務(wù)模型和業(yè)務(wù)邏輯，它與具體的技術(shù)框架無關(guān)，只專注于業(yè)務(wù)本身，領(lǐng)域?qū)邮浅恋眍I(lǐng)域知識的地方，是業(yè)務(wù)人員和技術(shù)人員溝通的基礎(chǔ)和橋梁。3.3.4 類層次設(shè)計(jì)最后是類層次，類是系統(tǒng)構(gòu)建的最小模塊，該層次關(guān)注組件里具體要設(shè)計(jì)哪些類，每個類的職責(zé)是什么，類與類之間的關(guān)系是怎樣的，類層次偏細(xì)節(jié)，這里就不詳細(xì)展開。四、微服務(wù)架構(gòu)設(shè)計(jì)微服務(wù)架構(gòu)，是一種技術(shù)架構(gòu)方式。它將應(yīng)用構(gòu)建成一系列按業(yè)務(wù)領(lǐng)域劃分的、小的自治服務(wù)。微服務(wù)被認(rèn)為是未來的方向，通

14、過將應(yīng)用和服務(wù)分解成更小的、松散耦合的組件，它們可以更加容易升級和擴(kuò)展。越來越多的互聯(lián)網(wǎng)公司使用這種架構(gòu)來部署自己的系統(tǒng)，有贊也不例外。微服務(wù)架構(gòu)有很多的好處：將巨大單體應(yīng)用拆分為多個微服務(wù)來解決復(fù)雜性問題。每個微服務(wù)可以由專門的團(tuán)隊(duì)來開發(fā)維護(hù)。每個微服務(wù)可以獨(dú)立部署、獨(dú)立擴(kuò)展。微服務(wù)架構(gòu)也有很多不足：微服務(wù)架構(gòu)是分布式架構(gòu)，會帶來分布式架構(gòu)固有的復(fù)雜性。數(shù)據(jù)庫分區(qū)帶來的數(shù)據(jù)一致性問題。測試一個基于微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)變得非常麻煩。微服務(wù)架構(gòu)實(shí)際上更多是技術(shù)實(shí)現(xiàn)和運(yùn)維部署的范疇，究竟如何拆分微服務(wù)，微服務(wù)架構(gòu)給不出答案。這就要用到應(yīng)用架構(gòu)的設(shè)計(jì)結(jié)果，上文中說到容器基本等同于限界上下文的概念，限

15、界上下文的劃分對指導(dǎo)微服務(wù)拆分有非常重要作用。一個微服務(wù)一般包含一到多個限界上下文，如何界定微服務(wù)需要包含幾個限界上下文？一是會根據(jù)限界上下文的業(yè)務(wù)復(fù)雜度來判斷，如果復(fù)雜度非常高，并且由多名開發(fā)人員維護(hù)，一般會單獨(dú)部署為一個微服務(wù)，獨(dú)立演進(jìn)。二是會根據(jù)技術(shù)復(fù)雜度來判斷，比如該業(yè)務(wù)域存在高并發(fā)、高可用、性能要求苛刻的場景，需要采用特殊的技術(shù)架構(gòu)，通常也會考慮單獨(dú)部署，與其他限界上下文在物理上隔離開。微服務(wù)架構(gòu)需要遵循逐步演進(jìn)的原則，多個限界上下文一開始通常部署在一個微服務(wù)中，隨著業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度上升，再逐步拆分為多個微服務(wù)。一開始就把微服務(wù)拆分得很細(xì)，會帶來大量分布式架構(gòu)的固有問題，可能業(yè)

16、務(wù)還沒發(fā)展起來，就被分布式的問題搞得焦頭爛額。下面介紹一下財(cái)務(wù)中臺的微服務(wù)架構(gòu)是如何演化。一開始業(yè)務(wù)比較簡單，為了方便部署維護(hù)，如上圖所示，所有限界上下文會部署到一個微服務(wù)中對外提供服務(wù)，但很快會遇到問題，業(yè)務(wù)越來越復(fù)雜，會與其他系統(tǒng)產(chǎn)生依賴關(guān)系。例如：供應(yīng)鏈系統(tǒng)的進(jìn)銷存場景會觸發(fā)財(cái)務(wù)中臺的核算業(yè)務(wù)，財(cái)務(wù)中臺需要依賴供應(yīng)鏈系統(tǒng)的庫存單據(jù)進(jìn)行核算，供應(yīng)鏈的某些場景也需要依賴財(cái)務(wù)中臺的能力，進(jìn)而會產(chǎn)生部署上的循環(huán)依賴，當(dāng)某個項(xiàng)目雙方互相依賴時，發(fā)布時就出現(xiàn)無法確定發(fā)布順序的難題，強(qiáng)行發(fā)布會導(dǎo)致發(fā)布期間一段時間內(nèi)部分功能不可用，不能平滑過渡。為了解決不能平滑發(fā)布的問題，可以將應(yīng)用層和領(lǐng)域?qū)舆M(jìn)行物理隔

17、離，分開部署。拿供應(yīng)鏈系統(tǒng)和財(cái)務(wù)中臺系統(tǒng)舉例，從業(yè)務(wù)定位來看，供應(yīng)鏈?zhǔn)秦?cái)務(wù)中臺的上游業(yè)務(wù)，供應(yīng)鏈的核心業(yè)務(wù)邏輯是完全不依賴財(cái)務(wù)業(yè)務(wù)的，因此供應(yīng)鏈領(lǐng)域?qū)拥南藿缟舷挛氖遣粫蕾囏?cái)務(wù)中臺領(lǐng)域?qū)拥南藿缟舷挛?。但某些?yīng)用場景，供應(yīng)鏈的應(yīng)用層需要編排財(cái)務(wù)中臺的數(shù)據(jù)給用戶展示，或觸發(fā)財(cái)務(wù)中臺的業(yè)務(wù)執(zhí)行，這時，只需要供應(yīng)鏈的應(yīng)用層依賴財(cái)務(wù)中臺的領(lǐng)域?qū)泳托?。所以，發(fā)布順序按照 1、2、3、4 的順序發(fā)布，就不會再出現(xiàn)部署上循環(huán)依賴的問題。隨著業(yè)務(wù)量爆發(fā)，不同限界上下文面臨的訪問量級是不一樣的，例如：核算域需要處理高并發(fā)量的業(yè)務(wù)單據(jù)核算，需要解決高并發(fā)、高性能等的技術(shù)問題，所以核算域會單獨(dú)分離出來，部署為微服務(wù)，

18、這樣就可以獨(dú)立設(shè)計(jì)和水平擴(kuò)展。但有些限界上下文盡量能部署在一起，例如結(jié)算域和單據(jù)明細(xì)域，因?yàn)橐坏┓珠_部署，會產(chǎn)生分布式事務(wù)問題，這會非常棘手，現(xiàn)實(shí)場景也遇到過微服務(wù)拆分后，分布式事務(wù)問題一直沒能很好解決，又把微服務(wù)合并了。所以如果不是遇到業(yè)務(wù)復(fù)雜度過高、高可用、高并發(fā)、高性能等問題，盡量不要把微服務(wù)拆分得很細(xì)，防止出現(xiàn)業(yè)務(wù)未發(fā)展起來，反而帶來一堆分布式架構(gòu)固有的復(fù)雜性問題。五、中臺、DDD 與微服務(wù)中臺的定義來源于阿里的中臺戰(zhàn)略（詳見企業(yè) IT 架構(gòu)轉(zhuǎn)型之道：阿里巴巴中臺戰(zhàn)略思想與架構(gòu)實(shí)戰(zhàn)鐘華編著），中臺的本質(zhì)是提煉各個業(yè)務(wù)線的共性需求，并將這些功能打造成組件化的產(chǎn)品。前臺要做什么業(yè)務(wù)，需要什么資源可以直接找中臺，不需要每次去改動自己的底層，而是在更豐富、靈活的“大中臺”基礎(chǔ)上獲取業(yè)務(wù)能力支持，讓“小前臺”更加靈活敏捷，中臺架構(gòu)被認(rèn)為是未來企業(yè)級架構(gòu)的方向。中臺、DDD 以及微服務(wù)屬于不同層面的內(nèi)容，中臺架構(gòu)是一種企業(yè)級的架構(gòu)模式，是從企業(yè)全局、整體視角來看的架構(gòu)全貌。DDD 是一套處理復(fù)雜業(yè)務(wù)的設(shè)計(jì)思想，里面的應(yīng)用層、