自從提倡 SOA 架構風格以來，個人覺得軟體架構并未有特别突破的變革，主要是在 SOA 面向服務架構風格基礎上不斷演化疊代，基于服務的 EA 明确分層架構也好，微服務也罷，都是在面向服務架構基礎上的适應不同的場景的疊代更新。
我先抛出一個觀點，我覺得服務化架構的本質，和西方教育界深受影響的古希臘哲學家蘇格拉底的“産婆術”的教育思想本質上是非常相通的：蘇格拉底的“産婆術”思想強調教育是一個“接生”的過程，教師就是“接生婆”，人們之是以接受教育是為了尋找“原我”以不斷完善自身。也就是教育的目的在于喚醒而不再于塑造。同理服務化架構的本質也不僅僅在采用什麼樣的技術架構實作和塑造，更重要的是在于通過不停地在共創中反問、反思、檢討等方式進行對業務的本質的不斷追溯、抽象、綜合歸納演繹，我們的每一個架構師都是服務化架構的接生婆，我們的使命是建立真正反映業務本質并驅動業務不斷向前的架構。
我們是否足夠深入了解業務的本質，做了足夠的歸納演繹以及綜合抽象，是否清晰的反應到了我們的服務化的根基：業務模型、域模型以及平台公共語義模型上？這是我們每一個參與服務化的每一個産品、架構師、TL 和核心開發同學需要回答的第一個根本問題。
定義
面向服務的架構（SOA）：SOA 是一種架構風格，緻力于将業務功能保持一緻的服務（系統服務，應用服務，技術服務）作為設計、建構和編排組合業務流程以及解決方案的基本單元。
目的
我們采用 SOA 的架構是為了什麼呢？
為了更好的複用？為了更好的責任切分？為了接口和實作的分離，提升靈活性和隔離性？還是為了更好的接口分類和管理？
以上說法其實都沒錯，但是面向服務化的架構 SOA 的目的遠遠超過接口技術細節的設計與定義，其核心的關注點在于服務的業務内容以及内涵，而不僅僅是如何設計和實作。
同時，SOA 更多的也不是如何建構一個服務，任何人都可以很容易地建立一個服務，這并不是 SOA 的核心挑戰，而是如何賦能企業建構有業務價值意義的完整業務語義的服務集合。
面向服務的架構緻力于在企業内的不同的業務環境内，建設業務功能驅動的服務，進而将服務組裝成有價值、更進階别的業務流程和解決方案平台。
面向服務的架構的真正的價值展現在當可重用的服務被靈活組合、編排在一起來建構靈活的、靈活的業務流程，其中靈活展現在服務可以快速調整，獨立演化；靈活性展現在服務由于其業務功能定義明确，邊界清晰且功能内聚性強，同時服務具備各自獨立完整生命周期，可被靈活組裝。
如果面向服務架構能為企業提供了重大的價值，那麼這些價值通過什麼來展現的呢？
價值展現
- 行為一緻性
面向服務的架構允許我們為業務流程、任務或者決策擁有唯一的共同的入口，也就是，不管服務通路的路徑如何，服務給業務提供的業務行為都是一緻的。
- 資料一緻性
面向服務的架構允許我們為業務資料資訊提供單一的通路入口，也就是它提供給業務一緻的、企業内部共識的公用資料通路。
- 子產品化及靈活性
面向服務的架構 SOA 為業務功能、業務決策和業務資訊的子產品化提供了非常好的機制。同時，在子產品化實作好的情況下，這些子產品可以在多個業務流程和場景中被靈活複用和重新組合，進而為業務競争力和創造性提供靈活性和靈活度支援。
- 功能與資料的解耦
面向服務的架構 SOA 提供了業務功能和資訊內建的同時，減少了他們之間的依賴和耦合性。也就是，獨立的業務功能單元，應用系統，可以一起協同工作，同時各自又具備各自的演進計劃，生命周期和業務目标。
- 高度可管理性
SOA 提供給我們通過定義服務水準協定在服務子產品粒度支撐我們的業務目标，我們可以不斷的設定、監控和優化調整元件，應用以及系統所承載服務的考核。
其中行為一緻性和資料一緻性作為服務的核心價值根基。
服務
一、定義
首先我們先定義一下服務是什麼？
服務是通過服務契約的方式來提供業務功能的獨立單元，同時受服務契約所明确管理。
服務是設計、建構和編排組合一個完整業務實體中業務解決方案的基礎單元。服務契約指定了服務消費方和提供方之間所有的互動約定，包括：
- 服務接口
- 接口文檔
- 服務政策
- 服務品質
- 服務可用性
- 性能
那我們經常聽到子產品、元件等其他的軟體構件，服務和他們有什麼差別呢？其中最核心的差別在于服務本身是被明确管理的，其服務品質和性能是通過服務水準協定（SLA）被明确管理的，而子產品以及元件并無此限制。此外，服務的全生命周期包含從設計、部署到增強更新和維護都是可管理的。
舉例（下列内容僅做示例展示用，非适用于嚴格場景）：
| 補貨計算服 | 性能要求 | ||
|---|---|---|---|
| 補貨建議量計算服務 | 針對行業下商家/供應商次元的入倉貨品補貨建議計算 | 在銷量預測符合分布要求且滿足準确率水準要求的情況下，根據缺貨率服務水準要求的産生的補貨建議量符合業務期望的周轉天數 | 10W + 貨品 * 30 倉，品+倉補貨及建議量 <= 30min |
| 訂單建立服務 | 包含購物車下單+立即下單場景，滿足所有優惠計算後的訂單生成 | 訂單建立成功率 99.999999999% | 峰值支撐：100w 單/s |
二、服務構成
服務自身主要包含兩個主要方面，第一方面也是服務最核心的方面就是服務的接口，另外一方面則是服務的實作。服務非常好的實作了接口和實作的分離。
1）服務接口
服務接口指定了服務的操作，也就是服務是做什麼的(What),操作的輸入輸出參數，以及用來約定如何使用和提供這些能力的協定。
服務通常包含圍繞着一個核心的業務功能操作以及相關聯的操作。例如補貨建議計算服務中核心的操作是生成貨品+倉次元的補貨建議單，其他相關操作包含查詢補貨建議單相關銷量預測操作，查詢補貨建議單對應計劃庫存操作。
| 核心功能操作 | 關聯操作 | |
|---|---|---|
| 補貨建議計算服務 | ||
| 品+倉次元補貨建議計算 | ||
| 補貨建議單對應銷量預測查詢 | ||
| 補貨建議單對應計劃庫存操作 |
2）服務實作
服務實作指的是服務如何通過其明确定義的接口提供其能力。服務實作可以通過以下方式實作：
- 完全基于編碼實作
- 基于其他服務的編排而成
- 基于已有應用适配封裝而成
- 以上情況混合實作
核心點是服務如何被實作的對于服務消費方來說是透明的，服務消費方僅僅需要關心的是服務是做什麼的，而不是如何被實作的。
服務可以提供在保持服務接口或者行為約定不改變的情況下，提供根據不同的行業不同場景提供各種不同的實作。
服務實作在保持服務接口或者行為約定不改變的情況下，可以自由進行更新和切換。服務實作既可以是靜态的更新更新，也可以使動态路由實時切換實作，如對應到不同的行業以及不同的業務場景的自動實作切換。
不管服務實作如何更新或者按需自動路由切換，隻用服務的行為和契約不會發生改變，使用者也就是服務的消費者根本不會感覺到任何不同。
我們可以把服務接口想象成室内普通電源國标插口，服務政策為室内非防水情況下适用，服務契約想象成 24X7 的 220v 電壓供電能力（其中 180V～250V 50Hz 是品質要求，24x7 穩定性要求，電流供給 <= 10A 是性能要求），此國标插座（服務提供方）可以給包含與此接口比對且符合契約的任何電器（消費方）互動并提供供電能力，支援其運轉。
服務接口定義了互動的的風格和細節，而服務的實作定義了一個特定的服務提供方或者特定的業務實作如何提供其能力。
這種類似連接配接點/插口的設計極大的友善了更松耦合的業務功能解決方案。
三、服務接口與服務實作的邏輯構成
服務接口與實作的構成也有兩個重要的不同方面，分别是執行功能的方法和執行的資訊資料。換句話說，一個服務是由一個業務服務操作集合以及對應操作的輸入輸出的抽象業務服務資料模型組成。這層業務服務資料模型是企業業務層次或者平台業務層次的業務實體的抽象，獨立于底層資料存儲與實作。此業務資料模型是和各子域密切相關聯，但是超越各子域以上的，在完整的業務線或者平台層次上達成一緻的業務資料模型，也就是說在各子域之間達成共識且約定的嚴格明确的公共模型，主要用于平台業務流程中不同域服務的互動，是平台層次統一的業務語言，我把它暫時稱為平台業務資料模型。 此平台業務資料模型通常需要包含平台統一語義的業務術語表，平台各域核心實體表，平台各域核心實體互動圖等。
接口與實作的邏輯構成：
1）服務操作
服務操作聲明定義了這個操作的輸入以及輸出參數。
2）平台業務實體模型
平台業務實體模型描述了服務中輸入輸出資料的結構以及含義。服務接口中的資訊和服
務實作中邏輯資料之間的差異是至關重要的。
在服務接口層次上，最重要的是資訊必須在業務服務之間進行互動來賦能業務流程并完成業務流程。這些資訊必須在參與流程的所有業務服務間達成一緻且在服務之間通用，也就是平台層次所有服務公用且标準的業務實體模型，同時此業務實體模型必須在平台業務語義上明确且完成，確定可以支撐平台所有端到端的業務。此平台層級的業務實體模型并不是一蹴而就的，但是可以随着平台的重心變化不斷疊代完善成型的。
然而不同的是，從内部來看，很多服務在各自實作的子域内部都有這些資訊的不同的超集，可能潛在的存在不同的資料格式。幸運的是，我們不需要感覺也不需要在所有關聯服務的相關子域實體模型上達成共識，即使不是不可能，但是也不太現實。與之相反，服務接口和服務實作的分離設計允許非常友善的進行平台業務實體模型和服務所在子域領域模型進行映射轉換。
3）服務接口最後一個重要的方面就是服務水準協定 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 方向來讨論不同的分層模型。
- Level 0：戰略與決策模型（高層戰略視角）
這層次模型用于定義企業的戰略方向和商業目的，進而定義了企業内任何系統平台開發的方向和終局。這必然作為企業内任何系統平台開發的基本背景和基調，影響任何系統平台開發項目的中長期目标定義和終局設定。
- Level 1：商業模式（業務線 owner 視角）
這層模型從業務線 owner 的視角，用營運主體的業務術語描述其商業模式的本質，包括其整體結構，業務流程，以及組織結構等。
- Level 2：業務抽象概念模型
這層模型從業務架構的視角用資訊化的方式對單個業務線或者多個業務線的業務進行抽象。Level 1 描述是對于企業業務來說有意義的東西或者事情，而 Level 2 則給予這些有意義的東西以更嚴格且清晰的定義，明确其内涵以及外延并體系化，同時根據不同行業線的業務内容進行提取抽象，抽象出共性的内容，用于更高效靈活的描述和定義業務 。
Level 1 描述的是業務營運人員所感覺的業務流程，Level 2 不僅描述了這些業務流程，更重要的是抽象并描述了了這些業務流程所應該包含的底層業務功能。
同樣的，Level 1 描述對企業業務來講所有重要的東西，Level 2 描述的是組織想要管理的資訊後面最根本的内容。Level 1 描述的事情是 Level 2 定義的基本實體的實際業務中對應的樣本或事例。
簡而言之，Level 2 是 Level 1 的抽象（Abstraction）與綜合（Synthesis）。 為了達成這一視圖，必須要仔細分析和歸納，有時候需要演繹的方式來定義出隐藏在企業業務營運主體視圖下根本結構和内容。
- Level 3：平台公共語義模型
Level 3 層公共語義模型同 Level 2 層業務概念模型保持緊密一緻，在此基礎上增加了服務化視角的語義。Level 3 公共語義模型描述的内容是在必須在平台層業務服務間共享的具有一緻語義的業務實體和資訊，是平台層一緻的共享資訊模型。這層模型用于描述平台層服務接口互動的共享資訊，基于平台完整業務語義下所有服務所公共資料的标準化視圖模型。簡而言之，平台公共語義模型，定義了業務平台層次基本業務服務語義，是平台各業務服務之間，平台業務流程和平台業務服務互動的統一語言。
- Level 4：域模型
Level 4 層域模型定位于平台各子域的領域模型/實體模型，用于對各子域的核心業務功能進行抽象。域模型是平台各子域的标準模型，不僅明确定義的各子域功能服務暨服務接口的語義，同時也包含各子域内服務實作中的關鍵實體的定義。域模型從整體上來說是平台各子域的私有模型，除了服務語義外整體不對外可視。公共資訊中的服務視圖是域模型的子集。
域模型核心用于除了用于暴露到平台子域的業務服務設計與實作外，同時也用于驅動域内服務功能的設計和實作。
域模型是需要保持動态穩定的，除非域内業務發生本質變化，域模型應該是相對穩定的。域模型穩定性最大的敵人是外部的依賴，如何不受外部依賴的侵蝕而逐漸腐敗，域防腐層存在的最主要原因。子域防腐層維護外部依賴服務和子域模型之間的動态映射，維護域模型的獨立性，保護域模型不受有害侵蝕。
域模型我了解基本和我們通常談的領域模型基本接近，對于各域内業務的抽象，驅動各域技術設計方案設計和實作，至于具體的模型表現形式，采用基于亞裡士多德的物質本源的思想（“Material Cause,Formal Cause,Efficient Cause,Final Cause" —> 實體+屬性+關系）的ER圖，還是基于我們老祖宗老子道家思想("人法地、地法天、天法道、道法自然" —> 實體+行為)的思想的領域驅動 DDD 的方式，個人認為各有伯仲，組中能清楚表達出業務本質即可，後面單獨寫一篇抽象模組化的文章聊一下這兩種不同的思想。
- Level 5：實作模型
此層模型為開發者視角的實作模型，也就是我們系統實作核心的對象模型，是我們系統落地的基石。
設計服務
我們初步了解的什麼是服務，以及什麼是服務化的分層？那如何設計服務以及服務化架構呢？下面給出基本步驟和方案。
一、了解整體背景
首先，我們要了解服務化架構的整體背景。我們必須了解我們所支撐的業務和業務根本驅動力以及所有的業務流程，業務場景以及業務用例；同時對于平台系統，我們還必須了解公司的戰略所賦予平台的使命是什麼？我們平台中長期的目标是什麼？平台的終局是什麼？這些組合和在一起才是服務化架構的完整的上下文背景。這些必須要反映到我們的業務模型、平台公共語義模型和各域模型中去。
然後，我們需要提出并回答如下問題：
- 我們目前支撐的是什麼樣的業務？（業務模型）
- 這個業務或者這些業務的中長期目标和短期目标分别是什麼？
- 平台的短中長期目标是什麼？平台的終局是什麼？
- 上述目标是否存在沖突，如何平衡和取舍？
- 實作這些目标，需要完成什麼樣的成果？
- 這些成果如何衡量？
- 取得這些成果，需要什麼樣的能力和資訊？
- 實作這些能力需要什麼樣的流程、服務、實體以及規則
- 現有的服務、應用或者系統提供了那些基本能力和資訊？
前面六個問題描述了整體的架構需求（包括業務和平台），而剩下的問題則描述了整個服務化架構的上下文以及引入了服務目錄庫的需求。我們服務不能隻從單個服務的角度來看，而必須從整個服務集合的角度來反應完整的業務語義和平台語義。我們的服務集合也就是服務目錄庫必須具備完整的上下文語義，必須能識别出：
- 整體的上下文背景，包括完整的業務語義和平台語義。
- 服務職責範圍
- 關聯的服務的分組
- 服務的類型和角色
服務目錄庫的設計必須支援兩個主要的設計時目标：
- 第一個目标是要提供一種機制來幫助了解服務整體的上下文背景，用于更好的服務選擇及更高效的服務重用。特别是，這個服務實作了什麼樣的責任，以及如何和其他的服務相關聯。
- 第二個目标是要提供一種機制來識别一個特定服務的責任邊界，用來指引服務的實作。這是一個非常關鍵的點，特别是在避免服務的功能和資料重複上非常重要，不僅僅是避免重複建設，更核心的是要以此保證業務功能和資料的一緻性。
服務目錄庫中的服務可以按照服務類型以及服務角色來進行組織。服務類型請參照服務化分層架構内容裡的描述；服務角色包含任務服務角色、實體服務角色和決策服務角色，請參照後面小節描述。
二、服務設計原則
面向服務化的架構的其中一個成功的關鍵是建立一個具備完整業務語義的服務集合以便于可以友善一起進行組合編排來支撐不同的業務流程以及豐富的業務場景。
我們經常談論各功能域要提供松耦合的服務，是因為服務間的松耦合是非常重要的，特别是通過減少服務間的依賴以便于服務可以在不同的場景中被複用，以及可以起到隔離變更影響的作用。但是如何才能盡可能的實作這個目标呢？
首先我們來看下對于服務最重要點是什麼？首先就是這個服務提供了什麼樣的業務功能，其次這個服務對業務有價值的資料産生了那些影響。從這兩個點上我們就可以比較
容易得出兩種類型的耦合在服務接口設計中是特别重要的：
- 資料依賴
- 功能依賴
舉例來說明下：
交易服務協調所有的活動，然後依賴其他服務來幫助完成流程。交易服務依賴于或者說耦合于使用者服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務等。
為啥交易服務沒有實作所有的功能？
首先是因為我們想在其他進階别流程或者服務中重用底層的能力。
第二是交易服務服務并不負責使用者服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務。交易服務隻是使用它們，而不是負責實作它們。
使用者服務被用作管理客戶資訊通路，它具有唯一的責任來提供、維護和更新客戶資訊，這樣做的目的是為了可以在任何需要通路客戶資料服務的地方重用客戶服務。比代碼重用更重要的是隔離或者是集中式通路客戶資訊，因為隻有唯一的路徑通路資料，資料就總是一緻的，真正實作 Source Of Truth。是以，盡管有很多服務包含交易服務，購物車，訂單曆史等服務需要通路客戶服務,通過松耦合的這種模式去管理這些依賴是比較容易被了解的。
通過建立服務來執行使用者管理，商品管理，庫存管理，以及營銷管理等，就可以在任何可以用到的地方，執行保持一緻性的這些業務功能。
敲黑闆：好的服務設計并不僅僅是關注重用性，更重要的是要提供一緻性,既包含功能一緻性，也包含資料一緻性。
那麼下一個問題是你如何決定有哪些服務以及這些服務分别是什麼呢？同樣，你用功能分解和資訊隔離組合在一起來決定服務有哪些并且各自是什麼？
- 對線上交易功能的分解引導去識别使用者、商品、庫存、營銷、訂單以及支付等相關功能服務。
- 對資訊的隔離引導我們去識别使用者和商品等作為交易訂單中的共享資訊。
- 面向服務的架構中服務設計的問題需要跨越多個以緻于所有的流程中來一起考慮。
是以，服務設計原則基本原則如下：
- 避免服務間的功能重複
- 避免服務間的功能缺失
- 避免資料重複
- 實作資料的協同通路
- 具備統一、一緻的方式來執行給定的功能
在服務化設計中，如何實作上述的這些原則呢？答案是提出并回答如下問題：
- 誰負責這個功能？
- 這個功能在哪裡被用到的？
- 誰負責管理這些指定的資料？
- 誰負責定義和實作那些特别的業務規則
- 流程中的哪個步驟具備執行這個任務所需要的特定的知識
這些問題的答案會幫你來識别如下資訊：
- 服務應該做什麼？
- 服務對什麼負責？
- 同樣重要的是，識别服務不應該做什麼，而應該依賴其他的服務來支撐
三、服務顆粒度與類型
我們通常設計服務時候一個很大的疑惑是我的服務到底要設計成什麼樣的顆粒度，應該更粗粒度一些，還是更細粒度一些？答案是：沒有一個統一正确的服務顆粒度标準。那怎麼辦？我如何設計我的服務的顆粒度呢？雖然沒有統一的标準，但是我們可以依賴下面的因素來決定合适的服務粒度：
- 誰是服務的潛在消費方？其他服務，業務流程還是外部合作方？
- 服務在哪裡被消費，通過什麼樣的路徑被消費，也就是服務的拓撲結構是什麼？
- 服務的性能要求是什麼？
- 服務預期的業務範圍或者邊界是什麼？
在幾乎任何複雜的環境或者系統平台中，我們可以預期到多種多樣類型的服務。這些服務具有不同的類型和顆粒度，可以參考服務化分層中的内容，也可以見下面的描述：
- 端到端的業務流程
業務流程通常跨越整個企業或者平台多個業務域，通常是由底層服務建構而成
業務服務是最粗粒度的服務，業務服務提供高度抽象的，組合的業務功能給到平台或者企業。業務服務的功能和資料同業務流程所需要的業務語義緊密結合。資料整合服務在這個層次提供端到端的業務流程所需要的整合後的資料。
子域服務是中等粒度的，他們提供特别針對于每個業務子域的業務相關服務,被本域内的不同業務服務所使用，但是未必暴露出子域外
子域基礎服務通常是最小粒度的服務，他們提供更低層次的服務，用來提供子域内子域業務功能的基本功能支撐
子域基礎服務通常也提供教小粒度的服務，用于支撐上層業務功能服務的業務功能完整實作。
基礎架構提供了在更高層級服務建構中細粒度的能力，獨立于任何業務域。這些服務需要和業務相關明确區分開來，例如安全認證，權限管理以及純粹技術編排服務。
四、服務角色
獨立于服務的粒度，職責範圍以及服務建立以外的另外一個重要考量或者說是側面是：服務在服務組合或者流程編排中所承擔的角色是什麼？
那麼怎麼來區分不同的角色呢？我們使用關注點隔離的架構原則。例如，我們在建構應用中就使用了将資料同邏輯隔離作為重要的概念。這樣不僅提供了不同關注點解耦的可能以及機會，而且允許采用不同的方式，在不同的地方來實作這些不同的關注點。
對業務流程進行單獨管理的BPM就是一個非常好的例子，BPM作為另外一個關注點分離的例子，将業務流程方案從其他邏輯中分離出來，可以使工作流程可以在一個特定的層次或者環境内進行執行和管理, 這樣就可以實作通過快速的建立新的流程模型來快速響應業務的變化。同時面向服務的架構SOA提供了将業務服務作為建構業務流程的基礎構件的功能。業務規則系統BRMS同樣也作為一個關注點分離的例子，将業務規則或者業務決策從其他應用邏輯中區分開來，這樣業務規則和業務決策也可以在一個特定的層次被執行和管理，進而就可以很容易的被變更來支援新的業務需求。這裡，業務規則以及決策服務也是面向服務的機構來暴露出規則和決策服務來支撐規則和決策與業務流程的分離。
通常我們通過較粗粒度的來定義三大類服務角色來建構不同的服務層次：
- 任務服務角色
任務服務通常實作一個完整的業務功能，既可以是基本業務功能，也可以是複雜的業務功能，如計算某個貨品在某個倉的補貨量，或者一個簡單的業務校驗，如此貨品在此倉是否可補。
此服務類型顆粒度範圍較廣，包含從獨立的子域基礎服務到大的平台業務服務都可以具有任務服務角色，更小顆粒度的服務傾向于具有更通用的目的,更大的可重用的潛力。業務服務幾乎總是承擔任務服務的角色，通常是小顆粒度服務較大的組合，可以被設計成支援一個或者更多特定的流程。是以這些服務通常在跨業務流程中廣泛複用的潛力更低。但是也是正常的，因為他們通常是有其他可重用的服務組成的。
通常，具有業務角色的服務是主動服務，通過主動行為來提供價值
- 實體服務角色
主要管理通路業務實體的服務具有這個角色。業務實體的例子如使用者、類目、商品、價格、庫存、購物車，主要對應主要的業務資訊。實體通常是中到大型實體，傾向于獨立于任何特定的業務流程,而可做為多個不同業務流程的組成部分。具有實體服務角色的服務通常通過适配和提供需要的資訊來實作任務的方式來支撐任務服務。實體服務通常都具備較大的重用的潛力。
- 規則 / 決策服務角色
規則 / 決策服務是通過執行業務規則來提供業務決策的服務，如補貨計劃自動稽核服務。
規則 / 決策服務通常用作對複雜問題進行判斷或者支援變化頻繁的業務規則，如複雜且多變的稽核規則等。
規則 / 決策服務通常為小到中等大小顆粒度，通常用來組裝成更大的服務。規則/決策服務是可以不同層次不同類型的服務，包括平台業務服務，子域服務，子域基礎服務等，但是通常情況下規則/決策服服務也來支撐這些服務類型。
我們通過組合這些不同類型的服務角色來提供靈活的業務能力，進而用來支援業務流程内的活動。我們提供了一些基本原則來幫助我們進行服務組合以便于幫我們減少依賴，限制耦合以及最大化靈活性。
服務層次以及組合基本原則：
- 業務流程的任務通過任務服務實作，業務流程路由的核心規則由規則/決策服務來提供，而不是定義在流程網關内。這一塊内容後續詳細說明。
- 更高層次的任務為核心的業務服務由其他更小的服務組成
- 服務依賴嚴格單向原則，上層服務可以依賴下層次服務以及同一層次服務，但是下層服務不可以依賴上層服務
- 一個任務服務可以組合規則/決策服務、實體服務以及其他任務服務
- 但是一個實體服務不允許直接調用其他實體服務
現在我們可以通過豐富的流程，實體和決策服務的集合，可以建立新的不同的服務組合，把規則的靈活可變的好處同服務化架構的子產品化，靈活性以及重用性結合起來作為業務系統平台級别的基本架構方式。
服務化如何成功？
一、大規劃
大的規劃首先要明确 2-3 年内的服務化的目标。大的規劃切記事無巨細，而是根據長期規劃設定明确的指導性原則和要求，在體系化的基礎上鼓勵協同和創新。
二、小目标
服務化不應該是運動式的大躍進推進，而應該是堅持試點、推廣、總結、擴大試點，進而由點到面，逐漸落實的方法，由各域根據規劃的體系化要求，再各自情況暨各自成熟度來設定各自服務化目标，制定一個個小目标，快速疊代，靈活式的總結推進。
三、真共識
建立共識的根本是要講清楚服務化的目标、架構、設計、開發背後的清楚的邏輯，讓每個人想的清楚，聽的明白。
四、接地氣
接地氣同達成共識一樣，要用樸素的工程師語言講清楚目标和邏輯，而不是拿各種看上去非常光鮮亮麗的各種名詞來充當台面，講的人解釋不清楚，聽得人一頭霧水，沒有體系化邏輯來支撐落地，最終很難達到服務化真正的目标的。
五、結硬寨
服務化是一個龐大的，疊代的，漸進的體系化工程，不是快閃戰，不是突襲戰，是場持久戰，一定要有曾國藩的“結硬寨，打呆仗”的耐心和準備，踏踏實實落地疊代推進，小步快跑，在堅持體系化思考的基礎上進行持續總結改進，通過一個接一個戰鬥，一個小勝利接一個小勝利，一個戰役接一個戰役不停的攻城略地的基礎上逐漸邁向成功。
六、Think Fast & Slow
一句話，高效的方式就是慢想、快幹。我們不一定缺少高執行力的人，但是一定缺少能獨立思考并體系化行事的人。