一、背景

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

二、財務中臺業(yè)務架構

2.1 零售整體業(yè)務架構

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

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

2.2 財務中臺業(yè)務架構

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

三、財務中臺應用架構

3.1 什么是應用架構？

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

3.2 如何設計應用架構？

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

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

3.3 財務中臺應用架構設計

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

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

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

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

3.3.3 組件層次設計

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

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

應用層容器內(nèi)通常沒有領域模型，因此也不需要訪問數(shù)據(jù)庫，因為它內(nèi)部主要是組合、編排的邏輯，如果出現(xiàn)類似領域模型的概念，要分析是不是有部分領域邏輯外泄到應用層，并考慮將領域邏輯下沉到領域層，以保證應用層的職責統(tǒng)一。上圖為領域層容器架構，分為接口層、應用層、領域層、防腐層、基礎設施層。

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

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

3.3.4 類層次設計

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

四、微服務架構設計

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

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

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

• 微服務架構是分布式架構，會帶來分布式架構固有的復雜性。
• 數(shù)據(jù)庫分區(qū)帶來的數(shù)據(jù)一致性問題。
• 測試一個基于微服務架構的應用系統(tǒng)變得非常麻煩。

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

五、中臺、DDD與微服務

中臺的定義來源于阿里的中臺戰(zhàn)略（詳見《企業(yè)IT架構轉型之道：阿里巴巴中臺戰(zhàn)略思想與架構實戰(zhàn)》鐘華編著），中臺的本質是提煉各個業(yè)務線的共性需求，并將這些功能打造成組件化的產(chǎn)品。前臺要做什么業(yè)務，需要什么資源可以直接找中臺，不需要每次去改動自己的底層，而是在更豐富、靈活的“大中臺”基礎上獲取業(yè)務能力支持，讓“小前臺”更加靈活敏捷，中臺架構被認為是未來企業(yè)級架構的方向。中臺、DDD 以及微服務屬于不同層面的內(nèi)容，中臺架構是一種企業(yè)級的架構模式，是從企業(yè)全局、整體視角來看的架構全貌。DDD 是一套處理復雜業(yè)務的設計思想，里面的應用層、領域層、應用服務、領域服務和中臺里很多概念一脈相承。微服務是技術實現(xiàn)和部署的范疇，它是落地中臺架構的技術工具。一張圖來表達他們之間的關系：
六、總結本文通過有贊零售財務中臺架構的實踐，詳細介紹了復雜業(yè)務系統(tǒng)的架構過程，首先基于整體業(yè)務架構，設計出系統(tǒng)的應用架構，應用架構有不同的設計粒度，可以參考 C4 模型從宏觀視角到微觀視角，逐步開展設計工作。接著，基于應用架構的限界上下文的劃分，可以指導我們進行微服務的拆分，通過對限界上下文復雜度的判斷，確定劃分為幾個微服務較為合適。最后介紹了中臺、DDD 與微服務之間的關系。通過這篇文章，希望能為開發(fā)者在架構設計上提供一些參考價值。

本文標題：有贊零售財務中臺架構設計與實踐-創(chuàng)新互聯(lián)
當前URL：http://aaarwkj.com/article40/hsoeo.html

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

廣告

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