SaaS 架構：應用服務、應用結構設計原則

應用架構設計通常包括以下步驟：

• • 根據業務架構，將業務需求轉化爲 IT 系統，識別核心應用服務。

• • 劃分應用結構，設計應用結構與業務流程、數據之間的關係。

• • 設計應用結構之間的交互和集成關係。

本文主要分享一下應用服務、應用結構設計設計。

應用服務設計

應用服務的概念

應用服務是對一個或一組密切相關的業務對象及其操作的封裝。

應用服務應明確定義其責任範圍，將相關業務功能和對象組合在一起，避免暴露內部細節。它需要整合因同一原因變化的功能和數據，同時分離因不同原因變化的部分。這種設計方法確保了服務的內聚性和靈活性。

應用服務的概念源於 SOA 和微服務架構的興起，通過將系統功能拆分爲多個獨立的服務，可以提高系統的可維護性、可擴展性和靈活性。

應用服務如何劃分？

應用服務在應用架構中起着至關重要的作用，它將系統的核心功能” 打包 “，並提供給外部的業務流程使用，可以視爲 SaaS 系統對外的 “門面”。

用戶或其他系統通過調用應用服務來實現特定的業務功能。那麼，如何設計應用服務呢？

1、對齊業務能力，設計顆粒度適中的服務，職責單一，避免跨服務調用。

在設計應用服務的粒度時，可以參考領域驅動設計（DDD）中的 "限界上下文" 概念。業務對象類似於限界上下文中的聚合根，是應用服務的核心。

通常情況下，每個業務能力都對應一到多個獨立的應用服務，同時每個應用服務也支持特定的業務能力。如圖所示。

如果一個應用服務支撐了過多的業務能力，需要評估其內部是否關聯了過多的業務對象。在這種情況下，可以考慮對多個業務對象進行分組，從而將該應用服務拆分爲多個更小、更專注的服務。

2、圍繞業務對象，提供具體的業務功能，具有明確的業務含義，不能包含不相關的功能。

從外部視角看來，應用服務通常是帶有明確的業務含義，一般圍繞某一個或一組密切相關的業務對象業務對象操作，不應該包含不相關的業務功能。

例如，” 商城交易服務” 專注於訂單確認、下單和支付等功能，不應處理用戶認證、商品推薦等其他業務。

3、服務可註冊、可監控、可度量

應用服務的公共 API 應註冊到 API 管理平臺，形成一份服務列表，供消費者訂閱調用。

應用服務對外提供服務時候，應能監控其運行狀態，並支持啓停操作。同時，服務應可度量，包括訂閱數量、調用次數、響應時間等指標。

服務化架構的價值

面向服務的架構最大的價值就在於它的敏捷性和靈活性。

敏捷性體現在服務可以快速調整，獨立演化。

靈活性則體現在每個服務都有清晰的業務邊界，功能內聚性強，能夠單獨管理生命週期。具體來說：

1. 1. 輕量級應用：採用基於服務設計的輕應用，各個服務獨立開發、部署和運營，可以獨立交付，影響範圍小，提升交付效率。
2. 2. 服務複用、靈活編排：通過服務的複用，柔性編排，可以快速響應業務的變化，支持複雜的業務流程。
3. 3. 局部擴展性高：系統被拆分爲獨立服務後，易於橫向擴展，只需擴展必要的部分，成本更低，效果更好。

示例：訂單履約能力的應用服務劃分

如圖所示，訂單履約能力是零售企業業務能力地圖中的 L2 業務能力。訂單履約能力可以細分爲多個末級業務能力：ToC 履約服務、訂單派單、訂單管理、揀貨管理、發貨管理和履約逆向。

基於這些末級業務能力，我們可以設計出相應的應用服務。

應用結構設計

應用結構描述了應用服務內部的層次結構和組織關係，它決定了系統的模塊化程度，以及後續的開發和維護難度。

應用結構的抽象層次

在應用結構設計中，我們通常會把系統抽象爲不同的層次。比如，將系統劃分爲系統級、應用級、模塊級和代碼級。

這種抽象級別的劃分幫助我們在不同層面處理複雜性，確保系統結構清晰且易於維護。如圖所示：

• • **系統級：**關注的是各個系統的整體佈局和治理方式，比如各個系統之間的關係，以及它們如何協同工作。

• • **應用級：**聚焦於各個應用的整體架構，包括應用與其他應用的交互方式，以及各個應用在整個系統中的角色。

• • **模塊級：**對應用內部的進一步細化，它涉及到代碼的模塊化設計、數據和狀態的管理等。通過合理的模塊劃分，可以提高代碼的可維護性、可重用性，減少重複勞動。

• • **代碼級：**關注的是代碼本身的結構和實現方式。這一層級的設計直接影響到代碼的質量和實現細節。

抽象級別的存在，主要是爲了幫助我們更好地管理系統的複雜性。

1、分解複雜度

如果將所有的細節混雜在一起，整個系統將變得難以理解、維護和擴展。通過設置不同的抽象級別，我們可以將系統的複雜性分解到各個層次，每個層次只需關注特定的功能和職責。

這種分層處理方式使開發人員在專注於系統某一部分時，無需過多關注其他部分的細節，從而大大簡化了系統的設計和開發過程。

2、團隊協作邊界清晰

在大型項目中，通常會有多個團隊並行開發。如果系統沒有明確的邊界，各團隊之間很容易產生衝突和重複勞動。

通過清晰的抽象級別劃分，不同團隊可以專注於系統的不同層次或模塊，互不干擾。

3、擴展性強

隨着業務需求的變化，系統往往需要不斷地擴展和升級。如果系統的架構設計沒有合理的抽象級別，擴展和升級就會變得異常困難，甚至可能引發系統的全面重構。

而在有抽象級別的系統中，變更往往只需要聚焦在特定的層次上進行，而不會影響整個系統。例如，一次業務改造隻影響模塊級別，我們可以在不改變系統整體架構的情況下，替換或新增某個模塊，以滿足新的業務需求。

應用結構如何劃分？

在前文中，我們提到應用服務的設計方法，那麼應用服務如何通過一步步轉化爲代碼結構呢？

應用服務會由一系列的應用結構來實現。如圖所示。

基於應用服務的劃分方案，我們可以進一步細化應用結構，以便更好地組織和管理系統功能。

這個過程涉及多個層次的設計方法：

• • 系統和子系統的劃分應與業務域和業務子域的粒度保持一致。這有助於我們更好地將業務需求映射到技術實現。

• • 一個或多個相關的應用服務可組合成一個可獨立部署的應用單元。

• • 應用單元內部可進一步分層。例如，參考領域驅動設計（DDD）的分層方法，可分爲用戶界面層、應用層、領域層和基礎設施層。

• • 應用單元各層級內部可細分爲多個模塊，每個模塊又包含多個代碼單元。

在上述設計方法中，一個應用服務可以單獨部署，也可以多個應用服務組合在一起部署。

那應用單元有哪些劃分的具體原則呢？應用的劃分原則可以參考以下：

1、業務劃分原則

最關鍵的是參考應用服務的劃分邊界。如果需要提高應用的粒度，可以參考業務域和業務子域的劃分。

將相同業務變更因素的功能和數據整合，提升系統內聚性。同時，把不同業務變更因素的功能和數據分開，減少系統耦合度。

2、技術劃分原則

在業務初期，儘量從單體應用開始，避免過早劃分應用單元，以減少分佈式數據庫事務和數據不一致的問題。

應用單元內部可進一步分層，避免應用間出現循環依賴或雙向依賴，始終保持不同層級間的單向依賴，高層級可以依賴低層級，同層級間不應互相依賴。

僅當真正遇到技術痛點時，例如規模、性能、安全等問題，才考慮拆分應用。如果不拆分會嚴重影響業務穩定性，則應進行拆分。不要爲了拆分而拆分，因爲每次拆分都會增加系統複雜度。

示例：訂單履約的應用結構劃分

如圖所示，是訂單履約的應用結構劃分。

應用層定義軟件的應用功能，它負責接收用戶請求，協調領域層能力來執行任務，並將結果返回給用戶，核心模塊包括：

• • C 端履約服務

• • 預計送達時間：爲消費者提供訂單的預計處理時間、配送時效等，通常基於訂單處理時間、配送情況、配送距離等多種因素計算。

• • 實時訂單狀態查詢：允許消費者實時查看他們的訂單所處階段。包括訂單待接單、揀貨、打包、已發貨、配送中等狀態。

• • 配送軌跡跟蹤：提供訂單從出庫到最終送達的完整路徑跟蹤，消費者可以查看訂單的當前位置和過往的配送節點，瞭解配送進度。

• • 配送信息修改：在訂單還未最終發出之前，消費者可能需要更改配送信息，如地址或配送時間。

• • 配送費用明細：顯示消費者的訂單配送費用的詳細分解，包括配送費、包裝費、服務費等。

• • 確認收貨：消費者可以通過系統確認收貨，是完成訂單流程的最後一步。

• • B 端管理模塊：

• • 訂單派單：接收來自銷售平臺的訂單，並按照既定規則自動分配給對應的門店 / 倉庫。

• • 訂單管理：全面管理訂單的生命週期，包括訂單的確認、處理、狀態跟蹤、修改和取消等管理操作。

• • 揀貨管理：管理倉庫內的揀貨操作，確保商品被準確無誤地從貨架上揀選出來，並進行打包和發貨。

• • 發貨管理：全面管理發貨單的生命週期，根據訂單的地址、商品大小、重量和客戶選擇的履約方式，匹配合適的發貨方式，並對發貨流程進行跟蹤。

• • 逆向履約：當客戶不滿意或需退換商品時，逆向履約模塊負責處理退貨請求，並管理退貨退款和換貨流程。

領域層是業務邏輯的核心，專注於表示業務概念、業務狀態流轉和業務規則，沉澱可複用的服務能力，模塊包括：

• • 履約服務表達：負責向客戶提供履約服務的明確信息。包括預計的送貨時間、費用計算、服務選項（如定時達、次日達等）以及履約可達性要求。

• • 訂單履約調度：提供訂單履約調度的核心能力，確保訂單被高效地處理和執行。它涉及訂單從接收到最終準備配送的所有調度和處理過程，包括訂單拆分、分配、揀貨、包裝、發貨等。

訂單履約系統與其他系統的依賴關係：

• • 商品管理系統：提供的商品信息，包括價格、規格、描述、分類、SKU 等。

• • 中央庫存系統：需要訪問中央庫存系統來確認下單商品的實物庫存情況，包括庫存數量和庫存位置。

• • 配送系統：一旦商品打包完成，將依賴配送系統來處理商品的實際配送工作，包括配送安排、跟蹤和狀態更新。配送系統提供的配送狀態和時間信息，對於訂單履約系統中訂單狀態的更新至關重要。

• • 基礎數據系統：提供組織機構信息、用戶權限信息、服務商信息等基礎數據。這些標準化的數據確保各個系統數據的一致性

• • 數據分析系統：訂單履約系統將產生大量數據，包括訂單數據、履約過程數據、配送時效數據等，這些數據需傳輸到數據分析系統。數據分析系統基於採集到的數據，提供分析與洞察，幫助優化訂單履約流程，提升客戶滿意度，並提供預測分析，來輔助庫存管理和需求預測。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Yd7ZisEE6pALVRoy-afM6g