有贊零售財務(wù)中臺架構(gòu)設(shè)計與實踐-創(chuàng)新互聯(lián)

一、背景

創(chuàng)新互聯(lián)從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站設(shè)計、做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元葉縣做網(wǎng)站,已為上家服務(wù),為葉縣各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108傳統(tǒng)模式下，企業(yè)的經(jīng)營活動會產(chǎn)生大量的業(yè)務(wù)數(shù)據(jù)。財務(wù)人員需要根據(jù)業(yè)務(wù)數(shù)據(jù)，進行會計核算，并輸出財務(wù)數(shù)據(jù)。通過這些財務(wù)數(shù)據(jù)，企業(yè)可以進行財務(wù)管理、財務(wù)分析、業(yè)務(wù)決策。但會計核算的工作量非常龐大，大多工作也比較基礎(chǔ)、簡單，可以被計算機替代。企業(yè)每年在基礎(chǔ)的核算工作上會花費大量的人力資源，在更重要的財務(wù)管理、財務(wù)分析、業(yè)務(wù)決策上無暇顧及。為了解決此類問題，財務(wù)中臺應(yīng)運而生。財務(wù)中臺是業(yè)務(wù)系統(tǒng)和財務(wù)總賬系統(tǒng)間的橋梁，通過匯集所有業(yè)務(wù)數(shù)據(jù)，進行篩選、核算、轉(zhuǎn)換，自動生成財務(wù)數(shù)據(jù)，并傳入財務(wù)總賬系統(tǒng)，節(jié)省大量會計核算的人工成本。除此之外，財務(wù)人員不需要在各個業(yè)務(wù)系統(tǒng)間來回切換，核對業(yè)務(wù)數(shù)據(jù)。財務(wù)中臺匯聚了所有財務(wù)數(shù)據(jù)，財務(wù)人員可以在統(tǒng)一的工作臺上進行數(shù)據(jù)核對和會計工作，不需要跨多個系統(tǒng)操作。通過財務(wù)中臺，可以輕松實現(xiàn)業(yè)財一體化，財務(wù)人員可以解放生產(chǎn)力，產(chǎn)出更高的價值。

二、財務(wù)中臺業(yè)務(wù)架構(gòu)

2.1 零售整體業(yè)務(wù)架構(gòu)

零售整體業(yè)務(wù)架構(gòu)分為前臺業(yè)務(wù)、總部中臺、企業(yè)/業(yè)務(wù)后臺。

前臺業(yè)務(wù)的特點是變化快、差異性大、細節(jié)體驗、跨平臺、多觸點。前臺業(yè)務(wù)幫助商家整合盡可能多的零售渠道進行銷售，以滿足顧客購物、娛樂和社交的綜合體驗需求?？偛恐信_從架構(gòu)上是串聯(lián)前臺業(yè)務(wù)和后臺業(yè)務(wù)，基于零售商家的核心經(jīng)營場景，建立會員、交易、營銷、運營、財務(wù)、數(shù)據(jù)等核心功能?？偛恐信_并不直接為商家和消費者提供應(yīng)用服務(wù)，它的主要職責(zé)是匯總所有業(yè)務(wù)數(shù)據(jù)，協(xié)同各個業(yè)務(wù)單元，提煉業(yè)務(wù)的共性需求，支撐前、后臺業(yè)務(wù)的快速發(fā)展。通過總部中臺，商家可以跟蹤和積累消費者的購物全渠道、全過程的數(shù)據(jù)，在這個過程中與消費者及時互動，掌握消費者在購買過程中的決策變化，給消費者個性化建議，提升購物體驗。再依靠大數(shù)據(jù)，對用戶做到精準(zhǔn)營銷、智能推薦商品；智能化采購更適合銷售的產(chǎn)品；做好財務(wù)管理，持續(xù)提升資金利用效率。企業(yè)/業(yè)務(wù)后臺包括采購要貨、供應(yīng)鏈、原材料管控、生產(chǎn)制造、合同管理、加盟代理、財務(wù)總賬等基礎(chǔ)業(yè)務(wù)。部分業(yè)務(wù)可能由商家的ERP系統(tǒng)完成，所以總部中臺和ERP系統(tǒng)會做好數(shù)據(jù)對接，商家的ERP系統(tǒng)仍然可以繼續(xù)使用。財務(wù)中臺屬于總部中臺的一部分，財務(wù)中臺通過匯集所有業(yè)務(wù)數(shù)據(jù)，進行篩選、核算、轉(zhuǎn)換，自動生成財務(wù)數(shù)據(jù)。同時，財務(wù)中臺提煉出財務(wù)相關(guān)的共性服務(wù)，支撐前、后臺業(yè)務(wù)的快速發(fā)展，幫助商家做好財務(wù)管理、財務(wù)分析和業(yè)務(wù)決策。

2.2 財務(wù)中臺業(yè)務(wù)架構(gòu)

財務(wù)中臺匯集全渠道銷售、供應(yīng)鏈、資產(chǎn)、營銷推廣等數(shù)據(jù)，自動完成會計核算，生成相應(yīng)的財務(wù)數(shù)據(jù)。同時，財務(wù)中臺可以進一步對接企業(yè)的財務(wù)總賬；為其他系統(tǒng)集成提供標(biāo)準(zhǔn)化的開放能力；為合作伙伴提供費用對賬等服務(wù)；為數(shù)據(jù)報表提供原始數(shù)據(jù)，加工出財務(wù)報表，為財務(wù)分析、業(yè)務(wù)決策提供有力的支持。

三、財務(wù)中臺應(yīng)用架構(gòu)

3.1 什么是應(yīng)用架構(gòu)？

應(yīng)用架構(gòu)定義了系統(tǒng)由哪些邏輯模塊組成，以及邏輯模塊之間的關(guān)系，也稱之為邏輯架構(gòu)圖。應(yīng)用架構(gòu)起到承上啟下的作用，一方面承接業(yè)務(wù)架構(gòu)的落地，一方面影響技術(shù)選型。

3.2 如何設(shè)計應(yīng)用架構(gòu)？

設(shè)計應(yīng)用架構(gòu)，首先要明確設(shè)計的粒度和層次，在不同粒度和層次，關(guān)注點是不一樣的。零售業(yè)務(wù)異常復(fù)雜，對于這種復(fù)雜業(yè)務(wù)，尤其要從宏觀到微觀逐層進行詳細的分析和設(shè)計，保證整體架構(gòu)的有序性和一致性。如果不這樣做，很容易讓產(chǎn)品技術(shù)團隊陷入混亂中，進而極大降低團隊的溝通和協(xié)作效率。這里可以結(jié)合 Simon Brown 提出的 C4 模型來考慮設(shè)計元素的粒度和層次。自上而下，Simon Brown 將整個軟件系統(tǒng)分為了四個層次，分別為系統(tǒng)上下文（System Context）、容器（Containers）、組件（Components）以及類（Classes），這些層次的說明如下所示。

• 系統(tǒng)上下文：是最高的抽象層次，代表了能夠提供業(yè)務(wù)價值的構(gòu)件。一個系統(tǒng)由多個獨立的容器構(gòu)成。
• 容器：是指一個在其內(nèi)部可以執(zhí)行組件或駐留數(shù)據(jù)的構(gòu)件。作為整個系統(tǒng)的一部分，容器通常是可執(zhí)行文件，但未必是各自獨立的進程。
• 組件：可以想象成一個或多個類組成的邏輯群組。組件通常由多個類在更高層次的約束下組合而成。
• 類：在一個面向?qū)ο蟮氖澜缋?，類是軟件系統(tǒng)的最小結(jié)構(gòu)單元。

3.3 財務(wù)中臺應(yīng)用架構(gòu)設(shè)計

那么，財務(wù)中臺系統(tǒng)在上述四個層次分別該如何設(shè)計？

3.3.1 系統(tǒng)上下文層次設(shè)計

首先是系統(tǒng)上下文層次，該層次會重點關(guān)注要設(shè)計的系統(tǒng)和其他系統(tǒng)之間的關(guān)系。財務(wù)中臺系統(tǒng)上下文的設(shè)計如下圖所示。3.3.2 容器層次設(shè)計其次是容器層次，該層次會將整個系統(tǒng)放大，關(guān)注系統(tǒng)內(nèi)部由哪些容器構(gòu)成，容器基本等同于限界上下文的概念。限界上下文的劃分是 DDD 戰(zhàn)略設(shè)計中的一部分，而且是最核心的設(shè)計工作，需要在該層次識別出限界上下文，這會對后續(xù)微服務(wù)架構(gòu)落地起到關(guān)鍵性作用。上圖為財務(wù)中臺系統(tǒng)內(nèi)應(yīng)用架構(gòu)圖，采用分層架構(gòu)模式，圖里的應(yīng)用層、領(lǐng)域?qū)印⒒A(chǔ)設(shè)施層和DDD中的概念一致，但它們是容器層次下的分層邏輯，視角是整個系統(tǒng)內(nèi)。對于單體系統(tǒng)來說，應(yīng)用層和領(lǐng)域?qū)舆壿嫊容^簡單，通常會合并為一個微服務(wù)部署，內(nèi)部也不會有非常清晰的限界上下文劃分。但對于企業(yè)級系統(tǒng)，業(yè)務(wù)邏輯非常復(fù)雜，內(nèi)部會劃分出眾多職責(zé)單一、功能完整的限界上下文，以保證系統(tǒng)架構(gòu)健康、有序地進行演進。

• 應(yīng)用層：應(yīng)用層是很薄的一層，應(yīng)用層內(nèi)的服務(wù)對應(yīng)一個具有業(yè)務(wù)價值的業(yè)務(wù)用例。它主要負責(zé)對領(lǐng)域服務(wù)進行組合和編排，負責(zé)處理業(yè)務(wù)用例內(nèi)的執(zhí)行順序以及結(jié)果的組裝，通過API網(wǎng)關(guān)向接入層提供服務(wù)。容器級應(yīng)用層涉及整個系統(tǒng)的邏輯，通常包含多個廉價的限界上下文，它們的內(nèi)部業(yè)務(wù)邏輯不會很復(fù)雜，但因為直接面向用戶，為了應(yīng)對快速變化的外部需求，應(yīng)用層變動會非常頻繁，它通過領(lǐng)域服務(wù)的組合和編排實現(xiàn)業(yè)務(wù)流程的快速適配上線。例如：上圖所示的結(jié)算管理是一個應(yīng)用層限界上下文，它為接入層提供與結(jié)算管理相關(guān)的應(yīng)用服務(wù)，它通過組合、編排領(lǐng)域?qū)拥暮怂阌?、結(jié)算域、收付域以及其他業(yè)務(wù)系統(tǒng)的領(lǐng)域服務(wù)，來實現(xiàn)自身應(yīng)用服務(wù)能力。
• 領(lǐng)域?qū)樱侯I(lǐng)域?qū)邮呛芎竦囊粚?，它是業(yè)務(wù)軟件的核心所在，包含了本領(lǐng)域所涉及的領(lǐng)域?qū)ο?、領(lǐng)域服務(wù)以及它們之間的關(guān)系，負責(zé)表達業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)信息以及業(yè)務(wù)規(guī)則。領(lǐng)域驅(qū)動設(shè)計提倡富領(lǐng)域模型，即盡量將業(yè)務(wù)邏輯歸屬到領(lǐng)域?qū)ο笊?，實在無法歸屬的部分則以領(lǐng)域服務(wù)的形式進行定義。用戶的需求經(jīng)常變化，但變化總是有規(guī)律的，用戶體驗、操作習(xí)慣、市場環(huán)境以及管理流程的變化，往往會導(dǎo)致界面邏輯、應(yīng)用邏輯變化，但核心領(lǐng)域邏輯不會有太大變化，所以領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯通常是共性的、穩(wěn)定的。容器級領(lǐng)域?qū)由婕罢麄€系統(tǒng)的邏輯，通常包含多個限界上下文，它們?yōu)檎w系統(tǒng)的微服務(wù)拆分提供依據(jù)。
• 基礎(chǔ)設(shè)施層：它向其他層提供通用的技術(shù)能力，例如：分布式通信能力、持久化能力、消息通信能力、任務(wù)調(diào)度能力等。

3.3.3 組件層次設(shè)計

再次是組件層次，該層次會將單個容器放大，組件是由一個或多個類組成的邏輯組，共同完成一類職責(zé)。在該層次會關(guān)注容器內(nèi)部是如何分層的，每層包含哪些邏輯組件。上圖為應(yīng)用層容器架構(gòu)，同樣采用分層架構(gòu)，包含接口層、應(yīng)用層、防腐層、基礎(chǔ)設(shè)施層。

• 接口層定義了提供給上層使用的服務(wù)協(xié)議（API），接口層的使用方通常是展現(xiàn)層。
• 這里的應(yīng)用層是更細粒度的、容器內(nèi)的層次，或者說是戰(zhàn)術(shù)級別的層次，根據(jù)復(fù)雜度不同，它通常包含一到多個限界上下文的應(yīng)用服務(wù)和業(yè)務(wù)組件，每個應(yīng)用服務(wù)通過編排其他限界上下文的服務(wù)，實現(xiàn)業(yè)務(wù)場景或業(yè)務(wù)用例。
• 防腐層用于和其他限界上下文集成，在防腐層內(nèi)部，你可以將自己的模型和外部模型進行轉(zhuǎn)換，防止受外部模型污染，進而讓內(nèi)部邏輯不穩(wěn)定。當(dāng)外部模型或接口協(xié)議發(fā)生變化時，只需要修改防腐層邏輯，不會影響到自身業(yè)務(wù)邏輯。

應(yīng)用層容器內(nèi)通常沒有領(lǐng)域模型，因此也不需要訪問數(shù)據(jù)庫，因為它內(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è)施層。

• 接口層定義了提供給上層使用的服務(wù)協(xié)議（API），接口層的使用方通常是應(yīng)用層容器。
• 應(yīng)用層通過編排領(lǐng)域?qū)拥念I(lǐng)域服務(wù)、領(lǐng)域模型以及少量外部服務(wù)來對外提供服務(wù)能力，這里強調(diào)少量的外部服務(wù)，是因為領(lǐng)域?qū)尤萜鲀?nèi)部的業(yè)務(wù)邏輯通常是共性的、穩(wěn)定的，它只會依賴比它更基礎(chǔ)、更穩(wěn)定的服務(wù)能力，而且依賴外部服務(wù)要盡可能少，這樣才能保證容器內(nèi)部的業(yè)務(wù)邏輯是共性的、穩(wěn)定的。
• 這里的領(lǐng)域?qū)邮歉毩６鹊摹⑷萜鲀?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)注存儲細節(jié)。在設(shè)計時，將倉儲接口放在領(lǐng)域?qū)?，而將倉儲的具體實現(xiàn)放在基礎(chǔ)設(shè)施層，領(lǐng)域?qū)油ㄟ^接口訪問數(shù)據(jù)存儲，而不必過多的關(guān)注倉儲存儲數(shù)據(jù)的細節(jié)，這樣使得領(lǐng)域?qū)訉⒏嗟年P(guān)注點放在領(lǐng)域邏輯上面。

領(lǐng)域?qū)尤萜骷軜?gòu)最核心的是領(lǐng)域?qū)?，它包含核心的業(yè)務(wù)模型和業(yè)務(wù)邏輯，它與具體的技術(shù)框架無關(guān)，只專注于業(yè)務(wù)本身，領(lǐng)域?qū)邮浅恋眍I(lǐng)域知識的地方，是業(yè)務(wù)人員和技術(shù)人員溝通的基礎(chǔ)和橋梁。

3.3.4 類層次設(shè)計

最后是類層次，類是系統(tǒng)構(gòu)建的最小模塊，該層次關(guān)注組件里具體要設(shè)計哪些類，每個類的職責(zé)是什么，類與類之間的關(guān)系是怎樣的，類層次偏細節(jié)，這里就不詳細展開。

四、微服務(wù)架構(gòu)設(shè)計

微服務(wù)架構(gòu)，是一種技術(shù)架構(gòu)方式。它將應(yīng)用構(gòu)建成一系列按業(yè)務(wù)領(lǐng)域劃分的、小的自治服務(wù)。微服務(wù)被認(rèn)為是未來的方向，通過將應(yīng)用和服務(wù)分解成更小的、松散耦合的組件，它們可以更加容易升級和擴展。越來越多的互聯(lián)網(wǎng)公司使用這種架構(gòu)來部署自己的系統(tǒng)，有贊也不例外。微服務(wù)架構(gòu)有很多的好處：

• 將巨大單體應(yīng)用拆分為多個微服務(wù)來解決復(fù)雜性問題。
• 每個微服務(wù)可以由專門的團隊來開發(fā)維護。
• 每個微服務(wù)可以獨立部署、獨立擴展。

微服務(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ù)實現(xiàn)和運維部署的范疇，究竟如何拆分微服務(wù)，微服務(wù)架構(gòu)給不出答案。這就要用到應(yīng)用架構(gòu)的設(shè)計結(jié)果，上文中說到容器基本等同于限界上下文的概念，限界上下文的劃分對指導(dǎo)微服務(wù)拆分有非常重要作用。一個微服務(wù)一般包含一到多個限界上下文，如何界定微服務(wù)需要包含幾個限界上下文？一是會根據(jù)限界上下文的業(yè)務(wù)復(fù)雜度來判斷，如果復(fù)雜度非常高，并且由多名開發(fā)人員維護，一般會單獨部署為一個微服務(wù)，獨立演進。二是會根據(jù)技術(shù)復(fù)雜度來判斷，比如該業(yè)務(wù)域存在高并發(fā)、高可用、性能要求苛刻的場景，需要采用特殊的技術(shù)架構(gòu)，通常也會考慮單獨部署，與其他限界上下文在物理上隔離開。微服務(wù)架構(gòu)需要遵循逐步演進的原則，多個限界上下文一開始通常部署在一個微服務(wù)中，隨著業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度上升，再逐步拆分為多個微服務(wù)。一開始就把微服務(wù)拆分得很細，會帶來大量分布式架構(gòu)的固有問題，可能業(yè)務(wù)還沒發(fā)展起來，就被分布式的問題搞得焦頭爛額。下面介紹一下財務(wù)中臺的微服務(wù)架構(gòu)是如何演化。一開始業(yè)務(wù)比較簡單，為了方便部署維護，如上圖所示，所有限界上下文會部署到一個微服務(wù)中對外提供服務(wù)，但很快會遇到問題，業(yè)務(wù)越來越復(fù)雜，會與其他系統(tǒng)產(chǎn)生依賴關(guān)系。例如：供應(yīng)鏈系統(tǒng)的進銷存場景會觸發(fā)財務(wù)中臺的核算業(yè)務(wù)，財務(wù)中臺需要依賴供應(yīng)鏈系統(tǒng)的庫存單據(jù)進行核算，供應(yīng)鏈的某些場景也需要依賴財務(wù)中臺的能力，進而會產(chǎn)生部署上的循環(huán)依賴，當(dāng)某個項目雙方互相依賴時，發(fā)布時就出現(xiàn)無法確定發(fā)布順序的難題，強行發(fā)布會導(dǎo)致發(fā)布期間一段時間內(nèi)部分功能不可用，不能平滑過渡。
為了解決不能平滑發(fā)布的問題，可以將應(yīng)用層和領(lǐng)域?qū)舆M行物理隔離，分開部署。拿供應(yīng)鏈系統(tǒng)和財務(wù)中臺系統(tǒng)舉例，從業(yè)務(wù)定位來看，供應(yīng)鏈?zhǔn)秦攧?wù)中臺的上游業(yè)務(wù)，供應(yīng)鏈的核心業(yè)務(wù)邏輯是完全不依賴財務(wù)業(yè)務(wù)的，因此供應(yīng)鏈領(lǐng)域?qū)拥南藿缟舷挛氖遣粫蕾囏攧?wù)中臺領(lǐng)域?qū)拥南藿缟舷挛?。但某些?yīng)用場景，供應(yīng)鏈的應(yīng)用層需要編排財務(wù)中臺的數(shù)據(jù)給用戶展示，或觸發(fā)財務(wù)中臺的業(yè)務(wù)執(zhí)行，這時，只需要供應(yīng)鏈的應(yīng)用層依賴財務(wù)中臺的領(lǐng)域?qū)泳托小Ｋ?，發(fā)布順序按照1、2、3、4的順序發(fā)布，就不會再出現(xiàn)部署上循環(huán)依賴的問題。
隨著業(yè)務(wù)量爆發(fā)，不同限界上下文面臨的訪問量級是不一樣的，例如：核算域需要處理高并發(fā)量的業(yè)務(wù)單據(jù)核算，需要解決高并發(fā)、高性能等的技術(shù)問題，所以核算域會單獨分離出來，部署為微服務(wù)，這樣就可以獨立設(shè)計和水平擴展。
但有些限界上下文盡量能部署在一起，例如結(jié)算域和單據(jù)明細域，因為一旦分開部署，會產(chǎn)生分布式事務(wù)問題，這會非常棘手，現(xiàn)實場景也遇到過微服務(wù)拆分后，分布式事務(wù)問題一直沒能很好解決，又把微服務(wù)合并了。所以如果不是遇到業(yè)務(wù)復(fù)雜度過高、高可用、高并發(fā)、高性能等問題，盡量不要把微服務(wù)拆分得很細，防止出現(xiàn)業(yè)務(wù)未發(fā)展起來，反而帶來一堆分布式架構(gòu)固有的復(fù)雜性問題。

五、中臺、DDD與微服務(wù)

中臺的定義來源于阿里的中臺戰(zhàn)略（詳見《企業(yè)IT架構(gòu)轉(zhuǎn)型之道：阿里巴巴中臺戰(zhàn)略思想與架構(gòu)實戰(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è)計思想，里面的應(yīng)用層、領(lǐng)域?qū)?、?yīng)用服務(wù)、領(lǐng)域服務(wù)和中臺里很多概念一脈相承。微服務(wù)是技術(shù)實現(xiàn)和部署的范疇，它是落地中臺架構(gòu)的技術(shù)工具。一張圖來表達他們之間的關(guān)系：
六、總結(jié)本文通過有贊零售財務(wù)中臺架構(gòu)的實踐，詳細介紹了復(fù)雜業(yè)務(wù)系統(tǒng)的架構(gòu)過程，首先基于整體業(yè)務(wù)架構(gòu)，設(shè)計出系統(tǒng)的應(yīng)用架構(gòu)，應(yīng)用架構(gòu)有不同的設(shè)計粒度，可以參考 C4 模型從宏觀視角到微觀視角，逐步開展設(shè)計工作。接著，基于應(yīng)用架構(gòu)的限界上下文的劃分，可以指導(dǎo)我們進行微服務(wù)的拆分，通過對限界上下文復(fù)雜度的判斷，確定劃分為幾個微服務(wù)較為合適。最后介紹了中臺、DDD 與微服務(wù)之間的關(guān)系。通過這篇文章，希望能為開發(fā)者在架構(gòu)設(shè)計上提供一些參考價值。

本文標(biāo)題：有贊零售財務(wù)中臺架構(gòu)設(shè)計與實踐-創(chuàng)新互聯(lián)
當(dāng)前URL：http://bm7419.com/article40/hsoeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、軟件開發(fā)、品牌網(wǎng)站制作、網(wǎng)站收錄、建站公司、手機網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)