大家好，我是湯師爺~
應用架構設計通常包括以下步驟：
- 根據業務架構，將業務需求轉化為IT系統，識別核心應用服務。
- 劃分應用結構，設計應用結構與業務流程、資料之間的關係。
- 設計應用結構之間的互動和整合關係。
本文主要分享一下應用服務、應用結構設計設計。
應用服務設計
應用服務的概念
應用服務是對一個或一組密切相關的業務物件及其操作的封裝。
應用服務應明確定義其責任範圍，將相關業務功能和物件組合在一起，避免暴露內部細節。它需要整合因同一原因變化的功能和資料，同時分離因不同原因變化的部分。這種設計方法確保了服務的內聚性和靈活性。
應用服務的概念源於SOA和微服務架構的興起，透過將系統功能拆分為多個獨立的服務，可以提高系統的可維護性、可擴充套件性和靈活性。
應用服務如何劃分？
應用服務在應用架構中起著至關重要的作用，它將系統的核心功能”打包“，並提供給外部的業務流程使用，可以視為SaaS系統對外的“門面”。
使用者或其他系統透過呼叫應用服務來實現特定的業務功能。那麼，如何設計應用服務呢？
1、對齊業務能力，設計顆粒度適中的服務，職責單一，避免跨服務呼叫。
在設計應用服務的粒度時，可以參考領域驅動設計（DDD）中的"限界上下文"概念。業務物件類似於限界上下文中的聚合根，是應用服務的核心。
通常情況下，每個業務能力都對應一到多個獨立的應用服務，同時每個應用服務也支援特定的業務能力。如圖所示。
如果一個應用服務支撐了過多的業務能力，需要評估其內部是否關聯了過多的業務物件。在這種情況下，可以考慮對多個業務物件進行分組，從而將該應用服務拆分為多個更小、更專注的服務。
2、圍繞業務物件，提供具體的業務功能，具有明確的業務含義，不能包含不相關的功能。
從外部視角看來，應用服務通常是帶有明確的業務含義，一般圍繞某一個或一組密切相關的業務物件業務物件操作，不應該包含不相關的業務功能。
例如，”商城交易服務”專注於訂單確認、下單和支付等功能，不應處理使用者認證、商品推薦等其他業務。
3、服務可註冊、可監控、可度量
應用服務的公共 API 應註冊到 API 管理平臺，形成一份服務列表，供消費者訂閱呼叫。
應用服務對外提供服務時候，應能監控其執行狀態，並支援啟停操作。同時，服務應可度量，包括訂閱數量、呼叫次數、響應時間等指標。
服務化架構的價值
面向服務的架構最大的價值就在於它的敏捷性和靈活性。
敏捷性體現在服務可以快速調整，獨立演化。
靈活性則體現在每個服務都有清晰的業務邊界，功能內聚性強，能夠單獨管理生命週期。具體來說：
- 輕量級應用：採用基於服務設計的輕應用，各個服務獨立開發、部署和運營，可以獨立交付，影響範圍小，提升交付效率。
- 服務複用、靈活編排：透過服務的複用，柔性編排，可以快速響應業務的變化，支援複雜的業務流程。
- 區域性擴充套件性高：系統被拆分為獨立服務後，易於橫向擴充套件，只需擴充套件必要的部分，成本更低，效果更好。
示例：訂單履約能力的應用服務劃分
如圖所示，訂單履約能力是零售企業業務能力地圖中的 L2 業務能力。訂單履約能力可以細分為多個末級業務能力：ToC 履約服務、訂單派單、訂單管理、揀貨管理、發貨管理和履約逆向。
基於這些末級業務能力，我們可以設計出相應的應用服務。
應用結構設計
應用結構描述了應用服務內部的層次結構和組織關係，它決定了系統的模組化程度，以及後續的開發和維護難度。
應用結構的抽象層次
在應用結構設計中，我們通常會把系統抽象為不同的層次。比如，將系統劃分為系統級、應用級、模組級和程式碼級。
這種抽象級別的劃分幫助我們在不同層面處理複雜性，確保系統結構清晰且易於維護。如圖所示：
- 系統級：關注的是各個系統的整體佈局和治理方式，比如各個系統之間的關係，以及它們如何協同工作。
- 應用級：聚焦於各個應用的整體架構，包括應用與其他應用的互動方式，以及各個應用在整個系統中的角色。
- 模組級：對應用內部的進一步細化，它涉及到程式碼的模組化設計、資料和狀態的管理等。透過合理的模組劃分，可以提高程式碼的可維護性、可重用性，減少重複勞動。
- 程式碼級：關注的是程式碼本身的結構和實現方式。這一層級的設計直接影響到程式碼的質量和實現細節。
抽象級別的存在，主要是為了幫助我們更好地管理系統的複雜性。
1、分解複雜度
如果將所有的細節混雜在一起，整個系統將變得難以理解、維護和擴充套件。透過設定不同的抽象級別，我們可以將系統的複雜性分解到各個層次，每個層次只需關注特定的功能和職責。
這種分層處理方式使開發人員在專注於系統某一部分時，無需過多關注其他部分的細節，從而大大簡化了系統的設計和開發過程。
2、團隊協作邊界清晰
在大型專案中，通常會有多個團隊並行開發。如果系統沒有明確的邊界，各團隊之間很容易產生衝突和重複勞動。
透過清晰的抽象級別劃分，不同團隊可以專注於系統的不同層次或模組，互不干擾。
3、擴充套件性強
隨著業務需求的變化，系統往往需要不斷地擴充套件和升級。如果系統的架構設計沒有合理的抽象級別，擴充套件和升級就會變得異常困難，甚至可能引發系統的全面重構。
而在有抽象級別的系統中，變更往往只需要聚焦在特定的層次上進行，而不會影響整個系統。例如，一次業務改造隻影響模組級別，我們可以在不改變系統整體架構的情況下，替換或新增某個模組，以滿足新的業務需求。
應用結構如何劃分？
在前文中，我們提到應用服務的設計方法，那麼應用服務如何透過一步步轉化為程式碼結構呢？
應用服務會由一系列的應用結構來實現。如圖所示。
基於應用服務的劃分方案，我們可以進一步細化應用結構，以便更好地組織和管理系統功能。
這個過程涉及多個層次的設計方法：
- 系統和子系統的劃分應與業務域和業務子域的粒度保持一致。這有助於我們更好地將業務需求對映到技術實現。
- 一個或多個相關的應用服務可組合成一個可獨立部署的應用單元。
- 應用單元內部可進一步分層。例如，參考領域驅動設計（DDD）的分層方法，可分為使用者介面層、應用層、領域層和基礎設施層。
- 應用單元各層級內部可細分為多個模組，每個模組又包含多個程式碼單元。
在上述設計方法中，一個應用服務可以單獨部署，也可以多個應用服務組合在一起部署。
那應用單元有哪些劃分的具體原則呢？應用的劃分原則可以參考以下：
1、業務劃分原則
最關鍵的是參考應用服務的劃分邊界。如果需要提高應用的粒度，可以參考業務域和業務子域的劃分。
將相同業務變更因素的功能和資料整合，提升系統內聚性。同時，把不同業務變更因素的功能和資料分開，減少系統耦合度。
2、技術劃分原則
在業務初期，儘量從單體應用開始，避免過早劃分應用單元，以減少分散式資料庫事務和資料不一致的問題。
應用單元內部可進一步分層，避免應用間出現迴圈依賴或雙向依賴，始終保持不同層級間的單向依賴，高層級可以依賴低層級，同層級間不應互相依賴。
僅當真正遇到技術痛點時，例如規模、效能、安全等問題，才考慮拆分應用。如果不拆分會嚴重影響業務穩定性，則應進行拆分。不要為了拆分而拆分，因為每次拆分都會增加系統複雜度。
示例：訂單履約的應用結構劃分
如圖所示，是訂單履約的應用結構劃分。
應用層定義軟體的應用功能，它負責接收使用者請求，協調領域層能力來執行任務，並將結果返回給使用者，核心模組包括：
- C端履約服務
- 預計送達時間：為消費者提供訂單的預計處理時間、配送時效等，通常基於訂單處理時間、配送情況、配送距離等多種因素計算。
- 實時訂單狀態查詢：允許消費者實時檢視他們的訂單所處階段。包括訂單待接單、揀貨、打包、已發貨、配送中等狀態。
- 配送軌跡跟蹤：提供訂單從出庫到最終送達的完整路徑跟蹤，消費者可以檢視訂單的當前位置和過往的配送節點，瞭解配送進度。
- 配送資訊修改：在訂單還未最終發出之前，消費者可能需要更改配送資訊，如地址或配送時間。
- 配送費用明細：顯示消費者的訂單配送費用的詳細分解，包括配送費、包裝費、服務費等。
- 確認收貨：消費者可以透過系統確認收貨，是完成訂單流程的最後一步。
- B端管理模組：
- 訂單派單：接收來自銷售平臺的訂單，並按照既定規則自動分配給對應的門店/倉庫。
- 訂單管理：全面管理訂單的生命週期，包括訂單的確認、處理、狀態跟蹤、修改和取消等管理操作。
- 揀貨管理：管理倉庫內的揀貨操作，確保商品被準確無誤地從貨架上揀選出來，並進行打包和發貨。
- 發貨管理：全面管理發貨單的生命週期，根據訂單的地址、商品大小、重量和客戶選擇的履約方式，匹配合適的發貨方式，並對發貨流程進行跟蹤。
- 逆向履約：當客戶不滿意或需退換商品時，逆向履約模組負責處理退貨請求，並管理退貨退款和換貨流程。
領域層是業務邏輯的核心，專注於表示業務概念、業務狀態流轉和業務規則，沉澱可複用的服務能力，模組包括：
- 履約服務表達：負責向客戶提供履約服務的明確資訊。包括預計的送貨時間、費用計算、服務選項（如定時達、次日達等）以及履約可達性要求。
- 訂單履約排程：提供訂單履約排程的核心能力，確保訂單被高效地處理和執行。它涉及訂單從接收到最終準備配送的所有排程和處理過程，包括訂單拆分、分配、揀貨、包裝、發貨等。
訂單履約系統與其他系統的依賴關係：
- 商品管理系統：提供的商品資訊，包括價格、規格、描述、分類、SKU等。
- 中央庫存系統：需要訪問中央庫存系統來確認下單商品的實物庫存情況，包括庫存數量和庫存位置。
- 配送系統：一旦商品打包完成，將依賴配送系統來處理商品的實際配送工作，包括配送安排、跟蹤和狀態更新。配送系統提供的配送狀態和時間資訊，對於訂單履約系統中訂單狀態的更新至關重要。
- 基礎資料系統：提供組織機構資訊、使用者許可權資訊、服務商資訊等基礎資料。這些標準化的資料確保各個系統資料的一致性
- 資料分析系統：訂單履約系統將產生大量資料，包括訂單資料、履約過程資料、配送時效資料等，這些資料需傳輸到資料分析系統。資料分析系統基於採集到的資料，提供分析與洞察，幫助最佳化訂單履約流程，提升客戶滿意度，並提供預測分析，來輔助庫存管理和需求預測。
本文已收錄於，我的技術網站：tangshiye.cn 裡面有，演算法Leetcode詳解，面試八股文、BAT面試真題、簡歷模版、架構設計，等經驗分享。