概貌和說明

1.活性演進的：服務中心一定是不斷髮展的
2.多樣的：服務能力形式多樣
（1）依賴於介面的服務(RPC、Web API)
（2）依賴於工具的服務
（3）依賴於資料的服務：對大資料的分析能力
3.可再劃分的：服務中心是有劃分的，且可以進一步劃分的

共享服務的設計考慮和設計原則

一、考慮
不建議使用的標準：LOC(Line of Code)

設計層面：業務和系統建模主要是遵循面向物件的分析和設計方法
運營層面：應該是一個完整的業務模型，要有資料運營和業務整合的價值
工程層面：基於分散式架構的共享服務架構，解決了大規模應用的問題，也引入了分散式事務、問題排查等挑戰
不能圖一時之快把業務拆的太碎，到最後不得不用很大資源投入來解決技術上面對的問題

二、原則

1. 高內聚、低耦合原則

2. 資料完整性原則
   該原則可以認為是將高內聚低耦合原則穿透到資料模型層面
   服務化架構的一個很重要的業務價值就是資料模型的統一
   大資料思維：不光是業務邏輯的關鍵資料，還包括業務的相關性資料；不光是業務實時線上資料，還要考慮到離線計算的資料

3. 業務可運營性原則
   我們期望服務中心是可運營的，是承載業務邏輯、沉澱業務資料、產生業務價值的業務單元。
   業務的運營性的兩個層面
   沉澱階段：當業務處於快速生長期，這時候的運營目標是滿足上層的業務需求
   創新階段：運營業務內部孕育出來的創新想法
   * 基於統一的資料模型，低成本的引入大資料技術；讓資料來源、資料分析、業務生產形成閉環 *

   
   能否用大資料能力提升運營水平是服務中心原則之一

4. 漸進性的建設原則
   坑：
   拆得過細，有延遲太長的問題
   資料過於分散，有資料庫效能的問題和分散式事務的問題，服務介面過於龐大的問題
   服務化應該從簡單開始，用真實的業務需求錘鍊出穩定可靠的共享服務。

總結一下：由簡入深起步，高內聚，低耦合；兼顧資料建設；持續延展業務

補充內容

耦合性分類(低――高)

內聚性分類(低――高)

遺留問題：如何結合業務演化界定拆分邊界和粒度？
遺留問題：如何量化衡量？