一、業務架構之產品經理的職責

產品經理的職責用戶的原始需求往往是零散和碎片化的，產品經理的職責就是：告訴用戶，系統長什么樣子；告訴開發，他要實現什么功能。產品經理定義了系統的外表。產品經理的職責：1、收集用戶的原始需求，2、梳理成一個個業務流程，每個業務流程由多個業務步驟組成。一個業務步驟包含三部分的內容：輸入、輸出和業務功能。3、需求梳理好后，產品經理會把每個步驟具體化為頁面原型。在原型中，會以直觀的方式給出各個步驟的輸入或輸出，以及用戶的操作過程，最后再把這些頁面串起來，形成一個業務流程。業務流程例子：

按照業務域來劃分系統模塊，有多少業務領域，就有多個系統模塊，流程中的業務節點按照業務域的不同，可以劃分到不同的系統模塊。注意不是按照業務流程劃分，有多少業務流程，就有多少個系統模塊，這個對應關系比較直接，但實現起來很困難。而且這種模塊劃分的方式并沒有降低總的業務復雜度。

業務劃分的目標1、業務的可擴展業務架構設計要能支持打造一個柔性系統，通過提供良好的業務擴展性，允許業務不斷調整和快速生長。業務的主題是變化和創新，系統的主題是穩定和可靠。

2、業務的可復用首先，模塊的職責定位要非常清晰。對于模塊來說，在定位范圍內的職責要全部涵蓋到，而不在這個范圍的職責全部不要。其次，模塊的數據模型和接口設計要保證通用。架構師需要歸納業務場景，通過抽象提煉，形成通用化的設計，以此來滿足多個類似場景的需求。小提示：清晰的模塊定位和通用化設計，是模塊能夠復用的內在要求。最后，實現模塊的高復用，還需要做好業務的層次劃分。我們知道，越是底層的業務，它就相對更固定。模塊劃分是需要考慮的重要問題：業務復用性。復用其實也是業務擴展性的基礎。復用的分類復用有多種形式，它可以分為技術復用和業務復用兩大類。技術復用包括代碼復用和技術組件復用；業務復用包括業務實體復用、業務流程復用和產品復用。從復用的程度來看，從高到低，我們可以依次劃分為產品復用 > 業務流程復用 > 業務實體復用 > 組件復用 > 代碼復用。

代碼級復用和技術組件復用都屬于工具層面，它們的好處是在很多地方都可以用，但和業務場景隔得有點遠，不直接對應業務功能，因此復用的價值相對比較低。業務實體復用針對細分的業務領域，比如訂單、商品、用戶等領域。它對各個業務領域的數據和業務規則進行封裝，將它變成上層應用系統可以直接使用的業務組件。業務流程的復用針對的是業務場景，它可以把多個業務實體串起來，完成一個端到端的任務。相比單個的業務實體復用，業務流程的復用程度更高，業務價值也更大。最高層次的復用是對整個系統的復用，比如說一個 SaaS 系統（Software-as-a-Service），它在內部做了各種通用化設計，允許我們通過各種參數配置，得到我們想要的功能；或者說一個 PaaS（Platform-as-a-Service）平臺，它會提供可編程的插件化支持，允許我們“嵌入”外部代碼，實現想要的功能。從技術復用到業務復用，越往上，復用程度越高，復用產生的價值也越大，但實現起來也越復雜，它能復用的場景就越有限。但如果我們能進一步打造業務中間件，并在這個基礎上，形成業務平臺，這樣，我們就能實現更高的業務級復用，可以更高效地支持系統的快速落地。

二、業務架構之業務模塊構建

業務模塊構建要求每個模塊都代表了某個業務概念，或者說業務領域。模塊內部由數據和業務邏輯組成，其中數據是核心，業務邏輯圍繞著數據，對數據做進一步加工，方便外部使用。對模塊的要求：1、定位明確，概念完整。數據上，模塊需要覆蓋對應業務領域的全部數據；功能上，模塊要包含業務領域的全部功能。2、自成體系，粒度適中。粒度劃分得太小，導致系統的碎片化；體量過大的模塊，我們稱之為“腫瘤”，可維護性很差。3、依賴關系明確。簡化模塊的依賴關系，我們就要同時簡化依賴的方向和減少依賴的數量。避免松散的網狀結構，盡量把網狀結構轉化為層次結構。業務模塊的構建步驟構建步驟：通過構建合理的模塊體系，有效地控制系統復雜度，最小化業務變化引起的系統調整。打造可擴展的模塊體系：1、模塊拆分我們先對系統進行模塊化拆分，拆分有兩種方式：水平拆分和垂直拆分。水平拆分是指從上到下把系統分為多層，按照系統處理的先后順序，把業務拆分為幾個步驟。垂直拆分指的是按照不同的業務線拆分。一般做業務架構時，我們先考慮垂直拆分，從大方向上，把不同業務給區分清楚，然后再針對具體業務，按照業務處理流程進行水平拆分。舉例：

2、打造可擴展的模塊體系：模塊整合通用化整合：通用化指的是通過抽象設計，讓一個模塊具備通用的能力，能夠替代多個類似功能的模塊。平臺化整合：平臺化是把定位相同的模塊組織在一起，以組團的方式對外提供服務。對于外部系統來說，我們可以把這些模塊看成是一個整體，一起對業務場景提供全面的支撐。

三、業務架構之常見業務架構

服務端常見業務架構1、單體架構單體應用內部一般采用分層結構，從上到下，一般分為表示層、業務層、數據訪問層、DB 層。表示層負責用戶體驗，業務層負責業務邏輯，數據訪問層負責 DB 的數據存取。

2、分布式架構

分布式架構，簡單來說就是系統由多個獨立的應用組成，它們互相協作，成為一個整體。

3、傳統SOA 架構

4、新的 SOA 架構

5、微服務架構

終端常見業務架構分布式的系統架構App 前端直接對接多個后端應用提供的 HTTP 接口。每個業務線的服務端進行拆分，讓 App 接口和 PC 端接口各自在物理上獨立，但它們共享核心的業務邏輯。

App 前端會通過移動網關來訪問服務端接口。這里的網關主要就是負責處理通用的系統級功能，包括通信協議適配、安全、監控、日志等等；網關處理完之后，會通過接口路由模塊，轉發請求到內部的各個業務服務，比如搜索服務、詳情頁服務、購物車服務等等。

四、業務架構之基礎服務的設計

1、基礎服務邊界劃分的原則

1）服務的完整性原則有些服務只是存儲基礎數據，然后提供簡單的增刪改查功能，這樣一來服務只是一個簡單的 DAO，變成了數據訪問通道。這樣的服務，它的價值就很有限，也容易被服務調用方質疑。劃分服務邊界時，要保證服務數據完整、功能全面，這樣才能支撐一個完整的業務領域。

2）服務的一致性原則服務內部的業務邏輯要盡量依賴內部數據，而不是接口輸入的數據，否則會造成數據和業務規則的脫節（一個在外面，一個在里面），如果服務對外部的依賴性很強，就無法提供穩定的能力了。

3）正交原則服務之間有數據的依賴關系，但沒有接口的調用關系。針對具體的業務場景，我們可以在上層的聚合服務里，通過聚合訂單服務和商品服務來實現。

2、基礎服務設計步驟先弄清做什么：服務邊界劃分，不主動調用其他服務、不負責和第三方系統的集成、只負責存儲，不負責數據的進一步解釋。怎么做：

1）部分字段可配置：如流程狀態等、也可配置主狀態和子狀態。基本狀態稱之為“主狀態”，數量是比較有限的，狀態之間的變化關系也是比較明確的，可以固定處理。子狀態有哪些具體的取值，不同的項目是不一樣的，可以開放給各個應用來定義。

2）拆分查詢等級：查詢接口可以根據返回字段數量的不同，提供三個不同粒度的查詢接口來滿足多樣化的需求。第一個是粗粒度接口，只返回訂單最基本的 7-8 個字段；第二個是中粒度接口，返回訂單比較常用的十幾個字段；第三個是細粒度接口，返回訂單的詳細信息。

3）設置不同等級的異步的消息通知。按照消息詳細程度的不同，訂單消息可以分為“胖消息”和“瘦消息”。顧名思義，胖消息包含了盡可能多的字段，但傳輸效率低；瘦消息只包含最基本的字段，傳輸效率高。如果外部系統需要更多的信息，它們可以通過進一步調用訂單服務的接口來獲取。