軟件架構雖然是個相對穩定的技術領域，但也在十年間經歷了從單體應用到 SOA 再到微服務的演化過程。但在本文作者看來，自SOA架構風格提倡以來，軟件架構並未有特別的突破，更多是在其之上做不斷的演化迭代。爲什麼呢？
Everything will be alright in the end, but if it is not alright, it’s not the end YET. —— True Grit Don’t take shortcuts. Don’t ask about what does not concern you. And don’t jump too quickly to conclusions.——Three Words of Wisdom The whole is greater than the sume of all parts. The whole has the properties its part do not have. — The concept of Emergence
前言
自從SOA架構風格提倡以來，個人覺得軟件架構並未有特別突破的變革：主要是在SOA面向服務架構風格基礎上不斷演化迭代。基於服務的EA明確分層架構也好，微服務也罷，都是在面向服務架構基礎上的適應不同的場景的迭代升級，同時DDD領域驅動也給面向服務架構設計提供了非常好的設計理念，所以我就想回歸到根本：面向服務的的架構來聊聊，可能有人說老生常談沒啥意思，沒關係，就當一個自己的思路整理，先聊10塊錢的。
面向服務的架構個人認爲我們花了非常多的精力在HOW上面，但是對服務是什麼（What）和爲什麼我們要服務化的架構（Why）重視度和花的精力是相對不足的。
我先拋出一個觀點，我覺得服務化架構的本質和西方教育界深受影響的古希臘哲學家蘇格拉底的“產婆術”的教育思想本質上是非常相通的：蘇格拉底的“產婆術”思想強調教育是一個“接生”的過程，教師就是“接生婆”，人們之所以接受教育是爲了尋找“原我”以不斷完善自身。也就是教育的目的在於喚醒而不再於塑造。同理服務化架構的本質也不僅僅在採用什麼樣的技術框架實現和塑造，更重要的是在於通過不停地在共創中反問、反思、反省等方式進行對業務的本質的不斷追溯、抽象、綜合歸納演繹，我們的每一個架構師都是服務化架構的接生婆，我們的使命是建立真正反映業務本質並驅動業務不斷向前的架構。
我們是否足夠深入理解業務的本質，做了足夠的歸納演繹以及綜合抽象，是否清晰的反應到了我們的服務化的根基：業務模型、域模型以及平臺公共語義模型上？這是我們每一個參與服務化的每一個產品、架構師、TL和核心開發同學需要回答的第一個根本問題。
爲了不產生概念的混淆和理解差異，我嘗試先對一些基礎的概念進行定義，各大組織定義各異，我選擇和自己的理解更接近的一些定義，在參考各大標準定義的基礎上加入了一點自己的理解。
術語
- 業務服務：提供增值價值的業務行爲或流程，其具有明確的業務功能定義，同時具有明確對應其價值的服務質量及水平衡量標準。
- 業務流程：通過獲取產出（如一系列產品後者服務）滿足客戶需求來實現特定業務價值的一系列業務行爲的有機組合。業務流程通常跨越整個平臺業務域，通常是由各域服務能力來支撐流程中的業務活動。
- 應用組件：按照一定的相關性進行進行結構化封裝的應用功能的一個集合，其目的是爲了 提升應用整體的一致性，靈活性，穩定性並實現重用。關鍵字：結構化封裝、一致性、靈活性、重用。
- 應用：一個應用組件的集合，其目的用來提供單個業務功能或者多個業務功能，從而爲整個系統或者平臺提供增量價值支撐。如供應鏈計劃域中的銷量計劃應用，計劃庫存應用，業務規則參數應用，補貨庫存平衡應用等。
- 系統：一系列應用以及服務的有機組合，具備端到端的完整業務功能，以體系化提供用戶增量價值爲核心目的。
- 平臺：一個或者多個系統的有機組合，具備整個業務線或者業務生態的端到端業務功能全集，以提升業務線或者業務生態整體業務價值爲目標。
- 架構：架構是一個系統的基礎組織構成，體現在其構成的組件集合，組件之間的關係以及與外部環境（人、系統、設備）的交互關係，以及指導系統設計和發展演進的原則
- 架構風格：架構風格是一系列符合共同原則和特徵的架構
定義
面向服務的架構(SOA)：
SOA 是一種架構風格，致力於將業務功能保持一致的服務（系統服務，應用服務，技術服務）作爲設計、構建和編排組合業務流程以及解決方案的基本單元。
目的
我們採用SOA的架構是爲了什麼呢？
爲了更好的複用？爲了更好的責任切分？爲了接口和實現的分離，提升靈活性和隔離性？還是爲了更好的接口分類和管理？
以上說法其實都沒錯，但是面向服務化的架構SOA目的是遠遠超過接口技術細節的設計與定義，其核心的關注點在於服務的業務內容以及內涵，而不僅僅是如何設計和實現。
同時，SOA更多的也不是如何構建一個服務，任何人都可以很容的創建一個服務，這並不是SOA的核心挑戰，而是如何賦能企業構建有業務價值意義的完整業務語義的服務集合
面向服務的架構致力於在企業內的不同的業務環境內，建設業務功能驅動的服務，從而將服務組裝成有價值、更高級別的業務流程和解決方案平臺。
面向服務的架構的真正的價值體現在當可重用的服務被靈活組合、編排在一起來構建敏捷的，靈活的業務流程，其中敏捷體現在服務可以快速調整，獨立演化；靈活性體現在服務由於其業務功能定義明確，邊界清晰且功能內聚性強，同時服務具備各自獨立完整生命週期，可被靈活組裝。
如果面向服務架構能爲企業提供了重大的價值，那麼這些價值通過什麼來體現的呢？
價值體現
- 行爲一致性 面向服務的架構允許我們爲業務流程、任務或者決策擁有唯一的共同的的入口，也就是，不管服務訪問的路徑如何，服務給業務提供的業務行爲都是一致的。
- 數據一致性 面向服務的架構允許我們爲業務數據信息提供單一的訪問入口，也就是它提供給業務一致的、企業內部共識的公用數據訪問。
- 模塊化及敏捷性 面向服務的架構SOA爲業務功能、業務決策和業務信息的模塊化提供了非常好的機制。同時，在模塊化實現好的情況下，這些模塊可以在多個業務流程和場景中被靈活複用和重新組合，從而爲業務競爭力和創造性提供靈活性和敏捷度支持。
- 功能與數據的解耦 面向服務的架構SOA提供了業務功能和信息集成的同時，減少了他們之間的依賴和耦合性。也就是，獨立的業務功能單元，應用系統，可以一起協同工作，同時各自又具備各自的演進計劃，生命週期和業務目標。
- 高度可管理性 SOA提供給我們通過定義服務水平協定在服務模塊粒度支撐我們的業務目標，我們可以不斷的設定、監控和優化調整組件，應用以及系統所承載服務的考覈。
其中行爲一致性和數據一致性作爲服務的核心價值根基。
服務
一、定義
首先我們先定義一下服務是什麼？
服務是通過服務契約的方式來提供業務功能的獨立單元，同時受服務契約所明確管理。
服務是設計、構建和編排組合一個完整業務實體中業務解決方案的基礎單元。服務契約指定了服務消費方和提供方之間所有的交互約定，包括：
- 服務接口
- 接口文檔
- 服務策略
- 服務質量
- 服務可用性
- 性能
那我們經常聽到模塊、組件等其他的軟件構件，服務和他們有什麼區別呢？其中最核心的區別在於服務本身是被明確管理的，其服務質量和性能是通過服務水平協定（SLA）被明確管理的，而模塊以及組件並無此約束。此外，服務的全生命週期包含從設計、部署到增強升級和維護都是可管理的。
舉例（下列內容僅做示例展示用，非適用於嚴格場景）
補貨計算服 | 服務策略 | 服務質量 | 性能要求 |
|---|---|---|---|
補貨建議量計算服務 | 針對行業下商家/供應商維度的入倉貨品補貨建議計算 | 在銷量預測符合分佈要求且滿足準確率水平要求的情況下，根據缺貨率服務水平要求的產生的補貨建議量符合業務期望的週轉天數 | 10W+貨品*30倉，品+倉補貨及建議量<=30min |
訂單創建服務 | 包含購物車下單+立即下單場景，滿足所有優惠計算後的訂單生成 | 訂單創建成功率99.999999999% | 峯值支撐：100w單/s |
二、服務構成
服務自身主要包含兩個主要方面，第一方面也是服務最核心的方面就是服務的接口，另外一方面則是服務的實現。服務非常好的實現了接口和實現的分離。
- 服務接口 服務接口指定了服務的操作，也就是服務是做什麼的(What),操作的輸入輸出參數，以及用來約定如何使用和提供這些能力的協議。 服務通常包含圍繞着一個核心的業務功能操作以及相關聯的操作。例如補貨建議計算服務中核心的操作是生成貨品+倉維度的補貨建議單，其他相關操作包含查詢補貨建議單相關銷量預測操作，查詢補貨建議單對應計劃庫存操作 服務 核心功能操作 關聯操作 補貨建議計算服務 品+倉維度補貨建議計算 補貨建議單對應銷量預測查詢 補貨建議單對應計劃庫存操作
- 服務實現
服務實現指的是服務如何通過其明確定義的接口提供其能力。服務實現可以通過以下方式實現：
- 完全基於編碼實現
- 基於其他服務的編排而成
- 基於已有應用適配封裝而成
- 以上情況混合實現
核心點是服務如何被實現的對於服務消費方來說是透明的，服務消費方僅僅需要關心的是服務是做什麼的，而不是如何被實現的。 服務可以提供在保持服務接口或者行爲約定不改變的情況下，提供根據不同的行業不同場景提供各種不同的實現。 服務實現在保持服務接口或者行爲約定不改變的情況下，可以自由進行升級和切換。服務實現既可以是靜態的更新升級，也可以使動態路由實時切換實現，如對應到不同的行業以及不同的業務場景的自動實現切換。 不管服務實現如何升級或者按需自動路由切換，只用服務的行爲和契約不會發生改變，用戶也就是服務的消費者根本不會感知到任何不同。 我們可以把服務接口想象成室內普通電源國標插口，服務策略爲室內非防水情況下適用，服務契約想象成24X7的220v電壓供電能力（其中180V～250V 50Hz是質量要求，24x7穩定性要求，電流供給<=10A是性能要求），此國標插座（服務提供方）可以給包含與此接口匹配且符合契約的任何電器（消費方）交互並提供供電能力，支持其運轉。 服務接口定義了交互的的風格和細節，而服務的實現定義了一個特定的服務提供方或者特定的業務實現如何提供其能力。 這種類似連接點/插口的設計極大的方便了更鬆耦合的業務功能解決方案。
三、服務接口與服務實現的邏輯構成
服務接口與實現的構成也有兩個重要的不同方面，分別是執行功能的方法和執行的信息數據。換句話說，一個服務是由一個業務服務操作集合以及對應操作的輸入輸出的抽象業務服務數據模型組成。這層業務服務數據模型是企業業務層次或者平臺業務層次的業務實體的抽象，獨立於底層數據存儲與實現。此業務數據模型是和各子域密切相關聯，但是超越各子域以上的，在完整的業務線或者平臺層次上達成一致的業務數據模型，也就是說在各子域之間達成共識且約定的嚴格明確的公共模型，主要用於平臺業務流程中不同域服務的交互，是平臺層次統一的業務語言，我把它暫時稱爲平臺業務數據模型。 此平臺業務數據模型通常需要包含平臺統一語義的業務術語表，平臺各域核心實體表，平臺各域核心實體交互圖等。
接口與實現的邏輯構成：
- 服務操作 服務操作聲明定義了這個操作的輸入以及輸出參數。
- 平臺業務實體模型 平臺業務實體模型描述了服務中輸入輸出數據的結構以及含義。服務接口中的信息和服務實現中邏輯數據之間的差異是至關重要的。 在服務接口層次上，最重要的是信息必須在業務服務之間進行交互來賦能業務流程並完成業務流程。這些信息必須在參與流程的所有業務服務間達成一致且在服務之間通用，也就是平臺層次所有服務公用且標準的業務實體模型，同時此業務實體模型必須在平臺業務語義上明確且完成，確保可以支撐平臺所有端到端的業務。此平臺層級的業務實體模型並不是一蹴而就的，但是可以隨着平臺的重心變化不斷迭代完善成型的。 然而不同的是，從內部來看，很多服務在各自實現的子域內部都有這些信息的不同的超集，可能潛在的存在不同的數據格式。幸運的是，我們不需要感知也不需要在所有關聯服務的相關子域實體模型上達成共識，即使不是不可能，但是也不太現實。與之相反，服務接口和服務實現的分離設計允許非常方便的進行平臺業務實體模型和服務所在子域領域模型進行映射轉換。
- 服務接口最後一個重要的方面就是服務水平協議SLA。服務水平SLA協議指定了服務的的兩個重要方面的指標，分別是業務上的指標和技術上的指標：
- 技術指標：響應時間RT，併發吞吐量Throughput，可用性Availability，可靠性Reliablity。
- 業務指標：完成的業務功能的質量或者完成度，如產生的補貨建議是否滿足業務預期的週轉缺貨KPI要求：週轉下降10天，缺貨率下降5%。
服務化分層架構
理解服務化分層架構，首先要對TOGAF Meta-Model有個清晰的理解，從元模型可以看出業務服務和業務流程的上承業務，下啓系統平臺的核心作用，一定要深刻理解業務服務和業務流程在企業架構中的重要性，下面我把我翻譯後畫的版本給大家放在這裏，給大家做個參考，TOGAF不多做解釋，如有需要，大家可以交流，後面有時間嘗試寫下我對TOGAF的學習和理解。
通常情況下，我們會按照不同行業的不同的業務流程去搭建系統，如供應鏈最初在大家電3W行業孕育，我們按照3W的行業和業務場景搭建了平臺商家相適應的計劃系統；後續自營行業又根據自己的行業也搭建了自營的計劃系統；後續小電數碼、國際以及其他業務快速發展，跟隨業務快跑的同時，也各自建立的各自的業務流程。在這個過程中，BPM爲建造不同的業務系統提供非常好的抽象支撐，但是經常的結果是，BPM被用作構建了更高層抽象的，也更高效的，但是卻是煙囪式的應用，而不沒有更好的貢獻更多的支撐到整體上能快速應對業務變化而更靈活，更敏捷的業務平臺或者系統。
而這正是面向服務的架構中業務規則以及決策作爲服務要發揮更大作用的地方。面向服務的架構允許我們將特定業務流程中的業務規則和業務決策抽象分離出來變成業務規則或者決策服務，這些規則和決策服務就可以被靈活應用到不同的業務流程中，從而這些服務可以被統一管理和演化升級。
BPM+SOA一起提供了支撐企業架構的完美組合。BPM提供更高層抽象定義業務流程的能力，以及與流程相關聯的重要監控和管理能力；業務服務提供了支撐業務流程的核心的功能、決策以及信息。面向服務的架構則提供能力將服務組合在一起來支撐和創建靈活且敏捷的端到端的企業業務。如果只有BPM而沒有SOA對於創建單獨的業務應用或許非常有用，但是通常是創建的煙囪式的應用，很難擴展到企業內或者平臺內不同的業務線。如果只有SOA而沒有BPM雖然可以創建可重用且一致性高的服務，但是缺少將這些服務快速搭建業務流程並支撐端到端業務的能力，也無法支撐建立具有競爭力且可以隨着外部競爭環境進行敏捷反應的業務。
下圖顯示了一個建議的的封層服務化架構圖，各分層如下：
- 端到端業務流程：業務流程是按照一定業務規則決定的順序執行的業務操作組成。高層級的業務功能，通常跨越應用域或者業務線。通常由行業開發團隊開發，此行業開發團隊可以具備明確的實現組織結構，也可以由跨團隊的相關域共同組成虛線團隊。例如，電商業務中，用戶選購下單交互流程；供應鏈業務中的補貨調撥計劃流程等。
- 平臺業務服務：高度模塊化的業務功能單元，由不同類型的子域服務組合編排而來，可作爲業務流程的編排單元。跨行業通用的業務服務可由功能所在覈心域開發團隊編排開發，行業內通用的業務服務可以由行業開發團隊負責編排開發。例如，補貨審批服務
- 子域服務：平臺各功能子域提供的服務，對平臺可見，用於平臺業務服務的組合編排，也可以作爲更高層的業務流程編排的基礎單元。子域服務通常由平臺各子域開發團隊負責開發。例如，銷量計劃服務，補貨建議計算服務。
- 子域基礎服務：用於支撐各功能子域服務的基礎服務，對子域可見，對平臺不可見，用於子域服務的編排。
- 子域基礎服務通常由平臺各子域開發團隊負責開發。例如，入倉決策服務，計劃單據服務，計劃庫存服務等。
- 基礎子域服務：或稱爲基礎業務域服務，提供平臺基礎業務服務，爲各個功能子域或平臺業務服務提供基礎業務功能及數據服務。例如：商家服務，貨品服務，庫存服務等。
- 基礎架構服務層：提供不同層次所公用的基礎架構服務，如用用戶管理，權限管理，操作審計等等。
我們通常按照上述分層結構來描述平臺架構或者企業內部架構，看上去好像層次結構清晰明瞭，但是卻是不完整的，因爲此面向服務的架構描述缺失了平臺系統架構中一個核心部分，暨信息及信息模型分層，這一點非常之關鍵，往往會決定架構的成功與否。
爲了使架構更完整同時也更真實，我們需要添加對應的完整信息抽象（實體模型 or 領域模型）：
- 核心單據模型：端到端業務流程中操作的核心單據，承載業務核心價值的信息單元模型，例如，銷售訂單，採購訂單，補貨計劃單等。此模型通常是平臺公共語義模型的核心子集。
- 平臺公共語義模型：定義了平臺層業務流程、業務服務交互數據。在平臺層面或企業層面，端到端業務流程中交互信息的公共語義模型，此模型不僅對平臺業務流程中交互的各實體進行了明確的定義，而且包含了業務流程中所需要的完整的業務語義實體，同時各業務語義實體邊界明確，責任清晰。核心單據模型通常是平臺公共語義模型的子集。平臺公共語義模型包含下層子域的對外服務實體子集，按照端到端的完整平臺業務語義，可由平臺各功能子域模型所共享給平臺的核心實體子集有機整合而成，也可由平臺業務模型全新定義，或者從TOP-DOWN以及BOTTOM-UP兩個方向共同融合而成。需要注意的是此模型必然是無法一蹴而就，需要經過無數迭代而不斷完善，但其一定是不可或缺的。平臺的諸多架構決策和不斷演化完善需要基於此模型來進行。
- 子域領域模型：平臺各功能子域的領域模型，用於驅動各功能子域的應用系統設計和開發。子域領域模型需要保持動態穩定，通過防腐層同所依賴的外域或者外部服務進行隔離，防止外部服務污染子域內的核心業務語義，同時保持域內業務功能靈活可控。子域領域模型僅通過其對外服務實體子集對外可見，其餘對外不可見。
- 跨域映射模型：用於各子域領域模型實現對外部模型的防腐依賴。
- 基礎架構服務層：提供不同層次所公用的基礎架構信息模型，如用戶模型，權限模型等。
信息架構模型框架
現在來討論下服務化分層架構重視度並不太高的另一個重要側面：信息架構，之所以說信息架構非常之重要，是因爲信息架構與服務化架構是一個密不可分的完整的整體。我對信息架構模型進行了分層劃分，下面從TOP_DOWN方向來討論不同的分層模型。
- Level0：戰略與決策模型（高層戰略視角） 這層次模型用於定義企業的戰略方向和商業目的，從而定義了企業內任何系統平臺開發的方向和終局。這必然作爲企業內任何系統平臺開發的基本背景和基調，影響任何系統平臺開發項目的中長期目標定義和終局設定。
- Level1：商業模式（業務線owner視角） 這層模型從業務線owner的視角，用運營主體的業務術語描述其商業模式的本質，包括其整體結構，業務流程，以及組織結構等。
- Level2: 業務抽象概念模型 這層模型從業務架構的視角用信息化的方式對單個業務線或者多個業務線的業務進行抽象。Level 1描述是對於企業業務來說有意義的東西或者事情，而Level2則給予這些有意義的東西以更嚴格且清晰的定義，明確其內涵以及外延並體系化，同時根據不同行業線的業務內容進行提取抽象，抽象出共性的內容，用於更高效靈活的描述和定義業務 。 Level1 描述的是業務運營人員所感知的業務流程，Level2不僅描述了這些業務流程，更重要的是抽象並描述了了這些業務流程所應該包含的底層業務功能。 同樣的，Level1描述對企業業務來講所有重要的東西，Level2描述的是組織想要管理的信息後面最根本的內容。Level1描述的事情是Level2定義的基本實體的實際業務中對應的樣本或事例。 簡而言之，Level2是Level1的抽象（Abstraction）與綜合(Synthesis). 爲了達成這一視圖，必須要仔細分析和歸納，有時候需要演繹的方式來定義出隱藏在企業業務運營主體視圖下根本結構和內容。
- Level3：平臺公共語義模型 Level3層公共語義模型同Level2層業務概念模型保持緊密一致，在此基礎上增加了服務化視角的語義。Level3公共語義模型描述的內容是在必須在平臺層業務服務間共享的具有一致語義的業務實體和信息，是平臺層一致的共享信息模型。這層模型用於描述平臺層服務接口交互的共享信息，基於平臺完整業務語義下所有服務所公共數據的標準化視圖模型。簡而言之，平臺公共語義模型，定義了業務平臺層次基本業務服務語義，是平臺各業務服務之間，平臺業務流程和平臺業務服務交互的統一語言。
- Level4：域模型 Level4層域模型定位於平臺各子域的領域模型/實體模型，用於對各子域的核心業務功能進行抽象。域模型是平臺各子域的標準模型，不僅明確定義的各子域功能服務暨服務接口的語義，同時也包含各子域內服務實現中的關鍵實體的定義。域模型從整體上來說是平臺各子域的私有模型，除了服務語義外整體不對外可視。公共信息中的服務視圖是域模型的子集。 域模型核心用於除了用於暴露到平臺子域的業務服務設計與實現外，同時也用於驅動域內服務功能的設計和實現。 域模型是需要保持動態穩定的，除非域內業務發生本質變化，域模型應該是相對穩定的。域模型穩定性最大的敵人是外部的依賴，如何不受外部依賴的侵蝕而逐漸腐敗，域防腐層存在的最主要原因。子域防腐層維護外部依賴服務和子域模型之間的動態映射，維護域模型的獨立性，保護域模型不受有害侵蝕。 域模型我理解基本和我們通常談的領域模型基本接近，對於各域內業務的抽象，驅動各域技術設計方案設計和實現，至於具體的模型表現形式，採用基於亞里士多德的物質本源的思想（“Material Cause,Formal Cause,Efficient Cause,Final Cause" —> 實體+屬性+關係）的ER圖，還是基於我們老祖宗老子道家思想(“人法地、地法天、天法道、道法自然” —> 實體+行爲)的思想的領域驅動DDD的方式，個人認爲各有伯仲，組中能清楚表達出業務本質即可，後面單獨寫一篇抽象建模的文章聊一下這兩種不同的思想。
- Level5：實現模型 此層模型爲開發者視角的實現模型，也就是我們系統實現核心的對象模型，是我們系統落地的基石。
設計服務
我們初步瞭解的什麼是服務，以及什麼是服務化的分層？那如何設計服務以及服務化架構呢？下面給出基本步驟和方案。
一、理解整體背景
首先，我們要理解服務化架構的整體背景。我們必須理解我們所支撐的業務和業務根本驅動力以及所有的業務流程，業務場景以及業務用例；同時對於平臺系統，我們還必須理解公司的戰略所賦予平臺的使命是什麼？我們平臺中長期的目標是什麼？平臺的終局是什麼？這些組合和在一起纔是服務化架構的完整的上下文背景。這些必須要反映到我們的業務模型、平臺公共語義模型和各域模型中去。
然後，我們需要提出並回答如下問題：
- 我們當前支撐的是什麼樣的業務？（業務模型）
- 這個業務或者這些業務的中長期目標和短期目標分別是什麼？
- 平臺的短中長期目標是什麼？平臺的終局是什麼？
- 上述目標是否存在衝突，如何平衡和取捨？
- 實現這些目標，需要完成什麼樣的成果？
- 這些成果如何衡量？
- 取得這些成果，需要什麼樣的能力和信息？
- 實現這些能力需要什麼樣的流程、服務、實體以及規則
- 現有的服務、應用或者系統提供了那些基本能力和信息？
前面六個問題描述了整體的架構需求（包括業務和平臺），而剩下的問題則描述了整個服務化架構的上下文以及引入了服務目錄庫的需求。我們服務不能只從單個服務的角度來看，而必須從整個服務集合的角度來反應完整的業務語義和平臺語義。我們的服務集合也就是服務目錄庫必須具備完整的上下文語義，必須能識別出：
- 整體的上下文背景，包括完整的業務語義和平臺語義。
- 服務職責範圍
- 關聯的服務的分組
- 服務的類型和角色
服務目錄庫的設計必須支持兩個主要的設計時目標：
- 第一個目標是要提供一種機制來幫助理解服務整體的上下文背景，用於更好的服務選擇及更高效的服務重用。特別是，這個服務實現了什麼樣的責任，以及如何和其他的服務相關聯。
- 第二個目標是要提供一種機制來識別一個特定服務的責任邊界，用來指引服務的實現。這是一個非常關鍵的點，特別是在避免服務的功能和數據重複上非常重要，不僅僅是避免重複建設，更核心的是要以此保證業務功能和數據的一致性。
服務目錄庫中的服務可以按照服務類型以及服務角色來進行組織。服務類型請參照服務化分層架構內容裏的描述；服務角色包含任務服務角色、實體服務角色和決策服務角色，請參照後面小節描述。
二、服務設計原則
面向服務化的架構的其中一個成功的關鍵是創建一個具備完整業務語義的服務集合以便於可以方便一起進行組合編排來支撐不同的業務流程以及豐富的業務場景。
我們經常談論各功能域要提供鬆耦合的服務，是因爲服務間的鬆耦合是非常重要的，特別是通過減少服務間的依賴以便於服務可以在不同的場景中被複用，以及可以起到隔離變更影響的作用。但是如何才能儘可能的實現這個目標呢？
首先我們來看下對於服務最重要點是什麼？首先就是這個服務提供了什麼樣的業務功能，其次這個服務對業務有價值的數據產生了那些影響。從這兩個點上我們就可以比較容易得出兩種類型的耦合在服務接口設計中是特別重要的：
- 數據依賴
- 功能依賴
舉例來說明下：
交易服務協調所有的活動，然後依賴其他服務來幫助完成流程。交易服務依賴於或者說耦合於用戶服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務等。
爲啥交易服務沒有實現所有的功能？
首先是因爲我們想在其他高級別流程或者服務中重用底層的能力。
第二是交易服務服務並不負責用戶服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務。交易服務只是使用它們，而不是負責實現它們。
用戶服務被用作管理客戶信息訪問，它具有唯一的責任來提供、維護和更新客戶信息，這樣做的目的是爲了可以在任何需要訪問客戶數據服務的地方重用客戶服務。比代碼重用更重要的是隔離或者是集中式訪問客戶信息，因爲只有唯一的路徑訪問數據，數據就總是一致的，真正實現 Source Of Truth。因此，儘管有很多服務包含交易服務，購物車，訂單歷史等服務需要訪問客戶服務,通過鬆耦合的這種模式去管理這些依賴是比較容易被理解的。
通過創建服務來執行用戶管理，商品管理，庫存管理，以及營銷管理等，就可以在任何可以用到的地方，執行保持一致性的這些業務功能。
敲黑板：好的服務設計並不僅僅是關注重用性，更重要的是要提供一致性,既包含功能一致性，也包含數據一致性。
那麼下一個問題是你如何決定有哪些服務以及這些服務分別是什麼呢？同樣，你用功能分解和信息隔離組合在一起來決定服務有哪些並且各自是什麼？
- 對線上交易功能的分解引導去識別用戶、商品、庫存、營銷、訂單以及支付等相關功能服務。
- 對信息的隔離引導我們去識別用戶和商品等作爲交易訂單中的共享信息。
面向服務的架構中服務設計的問題需要跨越多個以致於所有的流程中來一起考慮。
因此，服務設計原則基本原則如下：
- 避免服務間的功能重複
- 避免服務間的功能缺失
- 避免數據重複
- 實現數據的協同訪問
- 具備統一、一致的方式來執行給定的功能
在服務化設計中，如何實現上述的這些原則呢？答案是提出並回答如下問題：
- 誰負責這個功能？
- 這個功能在哪裏被用到的？
- 誰負責管理這些指定的數據？
- 誰負責定義和實現那些特別的業務規則
- 流程中的哪個步驟具備執行這個任務所需要的特定的知識
這些問題的答案會幫你來識別如下信息：
- 服務應該做什麼？
- 服務對什麼負責？
- 同樣重要的是，識別服務不應該做什麼，而應該依賴其他的服務來支撐
三、服務顆粒度與類型
我們通常設計服務時候一個很大的疑惑是我的服務到底要設計成什麼樣的顆粒度，應該更粗粒度一些，還是更細粒度一些？答案是：沒有一個統一正確的服務顆粒度標準。那怎麼辦？我如何設計我的服務的顆粒度呢？雖然沒有統一的標準，但是我們可以依賴下面的因素來決定合適的服務粒度：
- 誰是服務的潛在消費方？其他服務，業務流程還是外部合作方？
- 服務在哪裏被消費，通過什麼樣的路徑被消費，也就是服務的拓撲結構是什麼？
- 服務的性能要求是什麼？
- 服務預期的業務範圍或者邊界是什麼？
在幾乎任何複雜的環境或者系統平臺中，我們可以預期到多種多樣類型的服務。這些服務具有不同的類型和顆粒度，可以參考服務化分層中的內容，也可以見下面的描述：
- 端到端的業務流程 業務流程通常跨越整個企業或者平臺多個業務域，通常是由底層服務構建而成
- 平臺業務服務 業務服務是最粗粒度的服務，業務服務提供高度抽象的，組合的業務功能給到平臺或者企業。業務服務的功能和數據同業務流程所需要的業務語義緊密結合。數據整合服務在這個層次提供端到端的業務流程所需要的整合後的數據。
- 子域服務 子域服務是中等粒度的，他們提供特別針對於每個業務子域的業務相關服務,被本域內的不同業務服務所使用，但是未必暴露出子域外
- 子域基礎服務 子域基礎服務通常是最小粒度的服務，他們提供更低層次的服務，用來提供子域內子域業務功能的基本功能支撐
- 基礎子域服務 子域基礎服務通常也提供教小粒度的服務，用於支撐上層業務功能服務的業務功能完整實現。
- 基礎架構服務層 基礎架構提供了在更高層級服務構建中細粒度的能力，獨立於任何業務域。這些服務需要和業務相關明確區分開來，例如安全認證，權限管理以及純粹技術編排服務。
四、服務角色
獨立於服務的粒度，職責範圍以及服務創建以外的另外一個重要考量或者說是側面是：服務在服務組合或者流程編排中所承擔的角色是什麼？
那麼怎麼來區分不同的角色呢？我們使用關注點隔離的架構原則。例如，我們在構建應用中就使用了將數據同邏輯隔離作爲重要的概念。這樣不僅提供了不同關注點解耦的可能以及機會，而且允許採用不同的方式，在不同的地方來實現這些不同的關注點。
對業務流程進行單獨管理的BPM就是一個非常好的例子，BPM作爲另外一個關注點分離的例子，將業務流程方案從其他邏輯中分離出來，可以使工作流程可以在一個特定的層次或者環境內進行執行和管理, 這樣就可以實現通過快速的建立新的流程模型來快速響應業務的變化。同時面向服務的架構SOA提供了將業務服務作爲構建業務流程的基礎構件的功能。業務規則系統BRMS同樣也作爲一個關注點分離的例子，將業務規則或者業務決策從其他應用邏輯中區分開來，這樣業務規則和業務決策也可以在一個特定的層次被執行和管理，從而就可以很容易的被變更來支持新的業務需求。這裏，業務規則以及決策服務也是面向服務的機構來暴露出規則和決策服務來支撐規則和決策與業務流程的分離。
通常我們通過較粗粒度的來定義三大類服務角色來構建不同的服務層次：
- 任務服務角色 任務服務通常實現一個完整的業務功能，既可以是基本業務功能，也可以是複雜的業務功能，如計算某個貨品在某個倉的補貨量，或者一個簡單的業務校驗，如此貨品在此倉是否可補。 此服務類型顆粒度範圍較廣，包含從獨立的子域基礎服務到大的平臺業務服務都可以具有任務服務角色，更小顆粒度的服務傾向於具有更通用的目的,更大的可重用的潛力。業務服務幾乎總是承擔任務服務的角色，通常是小顆粒度服務較大的組合，可以被設計成支持一個或者更多特定的流程。因此這些服務通常在跨業務流程中廣泛複用的潛力更低。但是也是正常的，因爲他們通常是有其他可重用的服務組成的。 通常，具有業務角色的服務是主動服務，通過主動行爲來提供價值
- 實體服務角色 主要管理訪問業務實體的服務具有這個角色。業務實體的例子如用戶、類目、商品、價格、庫存、購物車，主要對應主要的業務信息。實體通常是中到大型實體，傾向於獨立於任何特定的業務流程,而可做爲多個不同業務流程的組成部分。具有實體服務角色的服務通常通過適配和提供需要的信息來實現任務的方式來支撐任務服務。實體服務通常都具備較大的重用的潛力。
- 規則/決策服務角色 規則/決策服務是通過執行業務規則來提供業務決策的服務，如補貨計劃自動審覈服務。 規則/決策服務通常用作對複雜問題進行判斷或者支持變化頻繁的業務規則，如複雜且多變的審覈規則等。 規則/決策服務通常爲小到中等大小顆粒度，通常用來組裝成更大的服務。規則/決策服務是可以不同層次不同類型的服務，包括平臺業務服務，子域服務，子域基礎服務等，但是通常情況下規則/決策服服務也來支撐這些服務類型。
我們通過組合這些不同類型的服務角色來提供靈活的業務能力，從而用來支持業務流程內的活動。我們提供了一些基本原則來幫助我們進行服務組合以便於幫我們減少依賴，限制耦合以及最大化靈活性。
服務層次以及組合基本原則：
- 業務流程的任務通過任務服務實現，業務流程路由的核心規則由規則/決策服務來提供，而不是定義在流程網關內。這一塊內容後續詳細說明。
- 更高層次的任務爲核心的業務服務由其他更小的服務組成
- 服務依賴嚴格單向原則，上層服務可以依賴下層次服務以及同一層次服務，但是下層服務不可以依賴上層服務
- 一個任務服務可以組合規則/決策服務、實體服務以及其他任務服務
- 但是一個實體服務不允許直接調用其他實體服務
現在我們可以通過豐富的流程，實體和決策服務的集合，可以創建新的不同的服務組合，把規則的靈活可變的好處同服務化架構的模塊化，靈活性以及重用性結合起來作爲業務系統平臺級別的基本架構方式。
服務化如何成功？
一、大規劃
大的規劃首先要明確2-3年內的服務化的目標：是快速地靈活支撐業務快跑？還是業務支撐目的已經初步達成，準備將成功經驗產品化輸出到業界？ 基於不同的目標的設定不同的規劃框架指導：
- 對於快速靈活支撐業務快跑爲服務化目標，核心指導原則是要要求提升對業務變化支撐的快速反應，產品技術可以不重複建設的基本原則上，較大程度允許各個子域百花齊放，返回各域主動性去提升對業務的支撐效率，最大程度提升研發效率，對業務的快速支撐。
- 而對於核心目的是準備將成功經驗輸出到業界，則核心指導原則則務必要求產品化，技術體系化爲首要指導原則，要求統一的可持續發展的技術體系和精益求精的產品設計體系。
大的規劃切記事無鉅細，而是根據長期規劃設定明確的指導性原則和要求，在體系化的基礎上鼓勵協同和創新。
二、小目標
服務化不應該是運動式的大躍進推進，而應該是堅持試點、推廣、總結、擴大試點，從而由點到面，逐步落實的方法，由各域根據規劃的體系化要求，再各自情況暨各自成熟度來設定各自服務化目標，制定一個個小目標，快速迭代，敏捷式的總結推進。
三、真共識
服務化要從上到下從目標到落地策略統一獲取共識，共識非常重要，要從技術高層到普通開發人員達成清晰明確的方向和落地體系。服務化是一個龐大的，迭代的，漸進的體系化工程，而不是一蹴而就的戰役式定勝負的項目，建立共識的根本是要講清楚服務化的目標、架構、設計、開發背後的清楚的邏輯，讓每個人想的清楚，聽的明白
四、接地氣
接地氣同達成共識一樣，要用樸素的工程師語言講清楚目標和邏輯，而不是拿各種看上去非常光鮮亮麗的各種名詞來充當檯面，講的人解釋不清楚，聽得人一頭霧水，沒有體系化邏輯來支撐落地，最終很難達到服務化真正的目標的。
借用毛主席在延安文藝座談會上的講話：
“我們的文藝工作者不熟悉工人，不熟悉農民，不熟悉士兵，也不熟悉他們的幹部。什麼是不懂？語言不懂，就是說，對於人民羣衆的豐富的生動的語言，缺乏充分的知識。許多文藝工作者由於自己脫離羣衆、生活空虛，當然也就不熟悉人民的語言，因此他們的作品不但顯得語言無味，而且裏面常常夾着一些生造出來的和人民的語言相對立的不三不四的詞句。許多同志愛說“大衆化”，但是什麼叫做大衆化呢？就是我們的文藝工作者的思想感情和工農兵大衆的思想感情打成一片。而要打成一片，就應當認真學習羣衆的語言。如果連羣衆的語言都有許多不懂，還講什麼文藝創造呢？英雄無用武之地，就是說，你的一套大道理，羣衆不賞識。在羣衆面前把你的資格擺得越老，越像個“英雄”，越要出賣這一套，羣衆就越不買你的賬。你要羣衆瞭解你，你要和羣衆打成一片，就得下決心，經過長期的甚至是痛苦的磨練。”
服務化落地的核心力量是一線工程師同學們，一定要用樸素的工程師語言講透講明白，讓工程師同學心中不惑，不能讓工程師同學來猜，猜來猜去，很多時候目標就偏了，時間就浪費了，信心就磨散了。
五、結硬寨
服務化是一個龐大的，迭代的，漸進的體系化工程，不是快閃戰，不是突襲戰，是場持久戰，一定要有曾國藩的“結硬寨，打呆仗”的耐心和準備，踏踏實實落地迭代推進，小步快跑，在堅持體系化思考的基礎上進行持續總結改進，通過一個接一個戰鬥，一個小勝利接一個小勝利，一個戰役接一個戰役不停的攻城略地的基礎上逐漸邁向成功。
六、Think Fast & Slow
一句話，高效的方式就是慢想、快乾，明確目標，規劃架構，設計實施方案和落地步驟都需要認真的、耐心的思考，理清頭緒，搭建體系化的邏輯支撐，剩下就是執行和落地了。我們不一定缺少高執行力的人，但是一定缺少能獨立思考並體系化行事的人。慢想，快乾說起來容易，但做起來難，要看有沒有耐心，能不能沉得住氣，而不是口號式的蠻幹，回頭看最有效率的一定是，Think Fast， Act Slow。
結尾&觀點
總體上來說，面向服務的架構通過應用分層架構的方式來分離業務流程和底層包括運營資源在內的各種資源，來支撐業務靈活性。
面向服務的架構提供的價值以及靈活性依賴於服務分層的質量，服務可以具有各種各樣的粒度和類型。服務顆粒度很重要，但是知道服務如何被使用一樣重要：服務在支撐業務流程上承擔了三種基本角色：任務服務角色，實體服務角色，決策服務角色。
面向服務的架構很早就作爲軟件業界特別是互聯網架構風格取向，然而服務化卻很難被真正成功的實現，原因多種多樣，這裏列一下一些相關的與此相關的個人的觀點，不喜可以隨便噴。
觀點1：
服務化失敗通常最最根本的問題不在於HOW：用何種技術來實現它，而在於WHAT：如何用業務本質的抽象來定義服務，定義分層，也就是首先摸摸揣在你胸口的業務本質WHY：業務模型以及域模型等，你想清楚了沒有？然後再想想如何利用服務分層和服務特性來搭建牛B的系統平臺
觀點2：
產品同學和技術同學各自在服務化架構承擔什麼角色？個人觀點如下：
- 業務平臺產品同學：最核心的角色和職責是業務架構師，也就是你要定義好整個平臺或者你所在域的業務模型，此模型必須可以完整且明確的表達平臺業務本質。
- 平臺架構師：最核心要的職責基於上層的業務模型結合各域公共語義來定義好： 1.完整的平臺公共語義模型；2.定義出各域業務責任邊界原則，用於職責劃分和判定，從而避免整體業務功能和業務數據不一致以及缺失。
- 各域架構師：最核心的責任定義所負責域的域模型(E/R模型或者領域模型)，然後基於此設計各域應用架構和數據架構。