一、背景

傳統模式下，企業的經營活動會產生大量的業務資料。財務人員需要根據業務資料，進行會計核算，並輸出財務資料。透過這些財務資料，企業可以進行財務管理、財務分析、業務決策。但會計核算的工作量非常龐大，大多工作也比較基礎、簡單，可以被計算機替代。企業每年在基礎的核算工作上會花費大量的人力資源，在更重要的財務管理、財務分析、業務決策上無暇顧及。為了解決此類問題，財務中臺應運而生。

財務中臺是業務系統和財務總賬系統間的橋樑，透過彙集所有業務資料，進行篩選、核算、轉換，自動生成財務資料，並傳入財務總賬系統，節省大量會計核算的人工成本。除此之外，財務人員不需要在各個業務系統間來回切換，核對業務資料。財務中臺匯聚了所有財務資料，財務人員可以在統一的工作臺上進行資料核對和會計工作，不需要跨多個系統操作。透過財務中臺，可以輕鬆實現業財一體化，財務人員可以解放生產力，產出更高的價值。

二、財務中臺業務架構

2.1 零售整體業務架構

零售整體業務架構分為前臺業務、總部中臺、企業/業務後臺。

前臺業務的特點是變化快、差異性大、細節體驗、跨平臺、多觸點。前臺業務幫助商家整合儘可能多的零售渠道進行銷售，以滿足顧客購物、娛樂和社交的綜合體驗需求。

總部中臺從架構上是串聯前臺業務和後臺業務，基於零售商家的核心經營場景，建立會員、交易、營銷、運營、財務、資料等核心功能。總部中臺並不直接為商家和消費者提供應用服務，它的主要職責是彙總所有業務資料，協同各個業務單元，提煉業務的共性需求，支撐前、後臺業務的快速發展。透過總部中臺，商家可以跟蹤和積累消費者的購物全渠道、全過程的資料，在這個過程中與消費者及時互動，掌握消費者在購買過程中的決策變化，給消費者個性化建議，提升購物體驗。再依靠大資料，對使用者做到精準營銷、智慧推薦商品；智慧化採購更適合銷售的產品；做好財務管理，持續提升資金利用效率。

企業/業務後臺包括採購要貨、供應鏈、原材料管控、生產製造、合同管理、加盟代理、財務總賬等基礎業務。部分業務可能由商家的ERP系統完成，所以總部中臺和ERP系統會做好資料對接，商家的ERP系統仍然可以繼續使用。

財務中臺屬於總部中臺的一部分，財務中臺透過彙集所有業務資料，進行篩選、核算、轉換，自動生成財務資料。同時，財務中臺提煉出財務相關的共性服務，支撐前、後臺業務的快速發展，幫助商家做好財務管理、財務分析和業務決策。

2.2 財務中臺業務架構

財務中臺彙集全渠道銷售、供應鏈、資產、營銷推廣等資料，自動完成會計核算，生成相應的財務資料。同時，財務中臺可以進一步對接企業的財務總賬；為其他系統整合提供標準化的開放能力；為合作伙伴提供費用對賬等服務；為資料包表提供原始資料，加工出財務報表，為財務分析、業務決策提供有力的支援。

三、財務中臺應用架構

3.1 什麼是應用架構？

應用架構定義了系統由哪些邏輯模組組成，以及邏輯模組之間的關係，也稱之為邏輯架構圖。應用架構起到承上啟下的作用，一方面承接業務架構的落地，一方面影響技術選型。

3.2 如何設計應用架構？

設計應用架構，首先要明確設計的粒度和層次，在不同粒度和層次，關注點是不一樣的。零售業務異常複雜，對於這種複雜業務，尤其要從宏觀到微觀逐層進行詳細的分析和設計，保證整體架構的有序性和一致性。如果不這樣做，很容易讓產品技術團隊陷入混亂中，進而極大降低團隊的溝通和協作效率。

這裡可以結合 Simon Brown 提出的 C4 模型來考慮設計元素的粒度和層次。自上而下，Simon Brown 將整個軟體系統分為了四個層次，分別為系統上下文（System Context）、容器（Containers）、元件（Components）以及類（Classes），這些層次的說明如下所示。

• 系統上下文：是最高的抽象層次，代表了能夠提供業務價值的構件。一個系統由多個獨立的容器構成。
• 容器：是指一個在其內部可以執行元件或駐留資料的構件。作為整個系統的一部分，容器通常是可執行檔案，但未必是各自獨立的程式。
• 元件：可以想象成一個或多個類組成的邏輯群組。元件通常由多個類在更高層次的約束下組合而成。
• 類：在一個物件導向的世界裡，類是軟體系統的最小結構單元。

3.3 財務中臺應用架構設計

那麼，財務中臺系統在上述四個層次分別該如何設計？

3.3.1 系統上下文層次設計

首先是系統上下文層次，該層次會重點關注要設計的系統和其他系統之間的關係。財務中臺系統上下文的設計如下圖所示。

3.3.2 容器層次設計

其次是容器層次，該層次會將整個系統放大，關注系統內部由哪些容器構成，容器基本等同於限界上下文的概念。限界上下文的劃分是 DDD 戰略設計中的一部分，而且是最核心的設計工作，需要在該層次識別出限界上下文，這會對後續微服務架構落地起到關鍵性作用。

上圖為財務中臺系統內應用架構圖，採用分層架構模式，圖裡的應用層、領域層、基礎設施層和DDD中的概念一致，但它們是容器層次下的分層邏輯，視角是整個系統內。

對於單體系統來說，應用層和領域層邏輯會比較簡單，通常會合併為一個微服務部署，內部也不會有非常清晰的限界上下文劃分。但對於企業級系統，業務邏輯非常複雜，內部會劃分出眾多職責單一、功能完整的限界上下文，以保證系統架構健康、有序地進行演進。

• 應用層：應用層是很薄的一層，應用層內的服務對應一個具有業務價值的業務用例。它主要負責對領域服務進行組合和編排，負責處理業務用例內的執行順序以及結果的組裝，透過API閘道器向接入層提供服務。容器級應用層涉及整個系統的邏輯，通常包含多個廉價的限界上下文，它們的內部業務邏輯不會很複雜，但因為直接面向使用者，為了應對快速變化的外部需求，應用層變動會非常頻繁，它透過領域服務的組合和編排實現業務流程的快速適配上線。例如：上圖所示的結算管理是一個應用層限界上下文，它為接入層提供與結算管理相關的應用服務，它透過組合、編排領域層的核算域、結算域、收付域以及其他業務系統的領域服務，來實現自身應用服務能力。
• 領域層：領域層是很厚的一層，它是業務軟體的核心所在，包含了本領域所涉及的領域物件、領域服務以及它們之間的關係，負責表達業務概念、業務狀態資訊以及業務規則。領域驅動設計提倡富領域模型，即儘量將業務邏輯歸屬到領域物件上，實在無法歸屬的部分則以領域服務的形式進行定義。使用者的需求經常變化，但變化總是有規律的，使用者體驗、操作習慣、市場環境以及管理流程的變化，往往會導致介面邏輯、應用邏輯變化，但核心領域邏輯不會有太大變化，所以領域層的業務邏輯通常是共性的、穩定的。容器級領域層涉及整個系統的邏輯，通常包含多個限界上下文，它們為整體系統的微服務拆分提供依據。
• 基礎設施層：它向其他層提供通用的技術能力，例如：分散式通訊能力、持久化能力、訊息通訊能力、任務排程能力等。

3.3.3 元件層次設計

再次是元件層次，該層次會將單個容器放大，元件是由一個或多個類組成的邏輯組，共同完成一類職責。在該層次會關注容器內部是如何分層的，每層包含哪些邏輯元件。

上圖為應用層容器架構，同樣採用分層架構，包含介面層、應用層、防腐層、基礎設施層。

• 介面層定義了提供給上層使用的服務協議（API），介面層的使用方通常是展現層。
• 這裡的應用層是更細粒度的、容器內的層次，或者說是戰術級別的層次，根據複雜度不同，它通常包含一到多個限界上下文的應用服務和業務元件，每個應用服務透過編排其他限界上下文的服務，實現業務場景或業務用例。
• 防腐層用於和其他限界上下文整合，在防腐層內部，你可以將自己的模型和外部模型進行轉換，防止受外部模型汙染，進而讓內部邏輯不穩定。當外部模型或介面協議發生變化時，只需要修改防腐層邏輯，不會影響到自身業務邏輯。

應用層容器內通常沒有領域模型，因此也不需要訪問資料庫，因為它內部主要是組合、編排的邏輯，如果出現類似領域模型的概念，要分析是不是有部分領域邏輯外洩到應用層，並考慮將領域邏輯下沉到領域層，以保證應用層的職責統一。

上圖為領域層容器架構，分為介面層、應用層、領域層、防腐層、基礎設施層。

• 介面層定義了提供給上層使用的服務協議（API），介面層的使用方通常是應用層容器。
• 應用層透過編排領域層的領域服務、領域模型以及少量外部服務來對外提供服務能力，這裡強調少量的外部服務，是因為領域層容器內部的業務邏輯通常是共性的、穩定的，它只會依賴比它更基礎、更穩定的服務能力，而且依賴外部服務要儘可能少，這樣才能保證容器內部的業務邏輯是共性的、穩定的。
• 這裡的領域層是更細粒度的、容器內的層次，或者說是戰術級別的層次。領域層包含各種領域模型，例如：領域實體、聚合根、領域服務、倉儲等。倉儲作為領域層和基礎設施層的連線元件，使得領域層不必過多的關注儲存細節。在設計時，將倉儲介面放在領域層，而將倉儲的具體實現放在基礎設施層，領域層透過介面訪問資料儲存，而不必過多的關注倉儲儲存資料的細節，這樣使得領域層將更多的關注點放在領域邏輯上面。

領域層容器架構最核心的是領域層，它包含核心的業務模型和業務邏輯，它與具體的技術框架無關，只專注於業務本身，領域層是沉澱領域知識的地方，是業務人員和技術人員溝通的基礎和橋樑。

3.3.4 類層次設計

最後是類層次，類是系統構建的最小模組，該層次關注元件裡具體要設計哪些類，每個類的職責是什麼，類與類之間的關係是怎樣的，類層次偏細節，這裡就不詳細展開。

四、微服務架構設計

微服務架構，是一種技術架構方式。它將應用構建成一系列按業務領域劃分的、小的自治服務。微服務被認為是未來的方向，透過將應用和服務分解成更小的、鬆散耦合的元件，它們可以更加容易升級和擴充套件。越來越多的網際網路公司使用這種架構來部署自己的系統，有贊也不例外。

微服務架構有很多的好處：

• 將巨大單體應用拆分為多個微服務來解決複雜性問題。
• 每個微服務可以由專門的團隊來開發維護。
• 每個微服務可以獨立部署、獨立擴充套件。

微服務架構也有很多不足：

• 微服務架構是分散式架構，會帶來分散式架構固有的複雜性。
• 資料庫分割槽帶來的資料一致性問題。
• 測試一個基於微服務架構的應用系統變得非常麻煩。

微服務架構實際上更多是技術實現和運維部署的範疇，究竟如何拆分微服務，微服務架構給不出答案。這就要用到應用架構的設計結果，上文中說到容器基本等同於限界上下文的概念，限界上下文的劃分對指導微服務拆分有非常重要作用。

一個微服務一般包含一到多個限界上下文，如何界定微服務需要包含幾個限界上下文？一是會根據限界上下文的業務複雜度來判斷，如果複雜度非常高，並且由多名開發人員維護，一般會單獨部署為一個微服務，獨立演進。二是會根據技術複雜度來判斷，比如該業務域存在高併發、高可用、效能要求苛刻的場景，需要採用特殊的技術架構，通常也會考慮單獨部署，與其他限界上下文在物理上隔離開。

微服務架構需要遵循逐步演進的原則，多個限界上下文一開始通常部署在一個微服務中，隨著業務複雜度和技術複雜度上升，再逐步拆分為多個微服務。一開始就把微服務拆分得很細，會帶來大量分散式架構的固有問題，可能業務還沒發展起來，就被分散式的問題搞得焦頭爛額。

下面介紹一下財務中臺的微服務架構是如何演化。

一開始業務比較簡單，為了方便部署維護，如上圖所示，所有限界上下文會部署到一個微服務中對外提供服務，但很快會遇到問題，業務越來越複雜，會與其他系統產生依賴關係。例如：供應鏈系統的進銷存場景會觸發財務中臺的核算業務，財務中臺需要依賴供應鏈系統的庫存單據進行核算，供應鏈的某些場景也需要依賴財務中臺的能力，進而會產生部署上的迴圈依賴，當某個專案雙方互相依賴時，釋出時就出現無法確定釋出順序的難題，強行釋出會導致釋出期間一段時間內部分功能不可用，不能平滑過渡。

為了解決不能平滑釋出的問題，可以將應用層和領域層進行物理隔離，分開部署。拿供應鏈系統和財務中臺系統舉例，從業務定位來看，供應鏈是財務中臺的上游業務，供應鏈的核心業務邏輯是完全不依賴財務業務的，因此供應鏈領域層的限界上下文是不會依賴財務中臺領域層的限界上下文。但某些應用場景，供應鏈的應用層需要編排財務中臺的資料給使用者展示，或觸發財務中臺的業務執行，這時，只需要供應鏈的應用層依賴財務中臺的領域層就行。所以，釋出順序按照1、2、3、4的順序釋出，就不會再出現部署上迴圈依賴的問題。

隨著業務量爆發，不同限界上下文面臨的訪問量級是不一樣的，例如：核算域需要處理高併發量的業務單據核算，需要解決高併發、高效能等的技術問題，所以核算域會單獨分離出來，部署為微服務，這樣就可以獨立設計和水平擴充套件。

但有些限界上下文儘量能部署在一起，例如結算域和單據明細域，因為一旦分開部署，會產生分散式事務問題，這會非常棘手，現實場景也遇到過微服務拆分後，分散式事務問題一直沒能很好解決，又把微服務合併了。所以如果不是遇到業務複雜度過高、高可用、高併發、高效能等問題，儘量不要把微服務拆分得很細，防止出現業務未發展起來，反而帶來一堆分散式架構固有的複雜性問題。

五、中臺、DDD與微服務

中臺的定義來源於阿里的中臺戰略（詳見《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》鍾華編著），中臺的本質是提煉各個業務線的共性需求，並將這些功能打造成元件化的產品。前臺要做什麼業務，需要什麼資源可以直接找中臺，不需要每次去改動自己的底層，而是在更豐富、靈活的“大中臺”基礎上獲取業務能力支援，讓“小前臺”更加靈活敏捷，中臺架構被認為是未來企業級架構的方向。

中臺、DDD 以及微服務屬於不同層面的內容，中臺架構是一種企業級的架構模式，是從企業全域性、整體視角來看的架構全貌。DDD 是一套處理複雜業務的設計思想，裡面的應用層、領域層、應用服務、領域服務和中臺裡很多概念一脈相承。微服務是技術實現和部署的範疇，它是落地中臺架構的技術工具。一張圖來表達他們之間的關係：

六、總結

本文透過有贊零售財務中臺架構的實踐，詳細介紹了複雜業務系統的架構過程，首先基於整體業務架構，設計出系統的應用架構，應用架構有不同的設計粒度，可以參考 C4 模型從宏觀視角到微觀視角，逐步開展設計工作。接著，基於應用架構的限界上下文的劃分，可以指導我們進行微服務的拆分，透過對限界上下文複雜度的判斷，確定劃分為幾個微服務較為合適。最後介紹了中臺、DDD 與微服務之間的關係。透過這篇文章，希望能為開發者在架構設計上提供一些參考價值。