今天整理和分享下流程驅動的SOA服務識別方法，該方法在傳統SOA架構規劃諮詢中應用比較多，對於當前的微服務架構規劃諮詢仍然可以參考借鑑。
服務識別整體流程說明
服務識別和服務需求分析的主要工作是基於SOA的需求分析方法論，以流程和業務驅動IT的指導思想，對業務系統進行業務建模，用例建模和業務實體建模，形成企業級需求和業務功能清單，作為後續服務識別的輸入。
對於服務需求，以流程分析為基礎，通過流程的逐層分解，細化出關鍵的業務活動，將流程活動識別為業務用例，並對業務用例進行建模。用例建模本身可以作為業務系統功能開發的需求規格說明書，同時對用例分析和功能操作的識別形成業務域-》流程分解-》用例-》業務操作的分解過程，用於後續服務的識別。
在整個分析過程中，流程的關鍵活動或業務用例的操作都會涉及到業務實體對象，因此需要對業務實體對象進行單獨建模，分析實體對象的關鍵屬性和對象間關係，同時分析實體對象和業務操作間的U/C矩陣，作為後續公用服務提取的基礎。
服務識別開始於需求分析，終止於識別出的候選服務列表。為了有效的實施SOA工程，應用不能孤立於其他應用而獨立開發。SOA的應用應該可以共享服務，這些服務不單單屬於某個獨立的應用，並且有自己的生命周期，能夠被獨立的管理。在SOA工程中，為了有效的管理需求，各個項目必須知道其他已經存在的項目、正在開發的項目以及未來將要開發的項目需求。所以，與SOA服務相關的需求應該在企業級層面管理。
對於服務本身可以分為業務服務，數據服務，技術服務等。從上圖也可以看到通過業務流程分析和業務架構梳理來識別業務服務；通過數據架構和數據建模來分析和識別數據服務；通過技術架構分析來識別關鍵的技術服務能力。
候選服務是被識別出用於系統重用的業務功能。一個候選服務不一定一對一的對應到實際交付的服務，比如，在分析階段，一個粗粒度的服務可能對應到需求中兩個或兩個以上的初始候選服務。另一方面，服務識別並不是簡單的識別出候選服務，也包括了一系列的校驗和評估。
服務識別整體方法
對於服務識別的方法，在前面很多文章都已經講到過，對於SOA實施中服務識別是相關重要的一個環節，如何基於業務驅動IT的思路，識別出真正粗粒度，高度自治，可復用的服務是後期服務治理管控能否順利的一個關鍵。否則SOA建設到後期很容易就變成一個數據集成平臺，而非是服務共享平臺。要知道服務的本質還是接口和交互，因此對於服務的識別總體來說兩種方法：
自頂朝下：基於業務流程分析入手，分析跨系統業務流程交互，識別出集成點和接口點，再轉化為服務自底朝上：基於當前遺留系統已有的系統間接口情況，分析接口對應的業務場景，再進行接口轉服務
可以看到不論是哪種方法，這裡面都有兩個重點，其一是必須要明確的清楚每一個服務的業務含義，對應的業務場景和業務交互點在哪裡？其次就是需要做接口轉服務這個關鍵動作。
1. 自頂朝下的服務識別
如果各個業務系統之間沒有業務和數據的交互，那麼跟根本不應該存在任何的接口或服務。而對於服務的存在原因主要還是我們的端到端業務流程往往是跨了多個業務系統的交互才能實現的，而這些跨業務系統的交互點要麼進行業務規則的校驗，要麼進行關鍵業務數據和單據的傳遞。
這些交互點和集成點都是潛在的接口服務識別點，通過這種方式識別出來的服務我們就很清楚服務對應的業務流程和場景。比如採購系統和ERP之間有一個採購訂單導入的接口服務，我們就很清楚整個供應鏈流程中，採購訂單的創建和生效是在採購系統裡面，但是基於採購訂單的採購接收和入庫是在ERP系統，因此需要將採購訂單同步到ERP系統中。
這種跨系統流程分析基本會把橫向的所有關鍵接口全部梳理出來，但是容易遺漏掉縱向的一些基礎數據共享接口，距離來說我們在擬制採購訂單的時候，是需要輸入和選擇項目信息，選擇對應的庫存組織信息的。而這些基礎數據需要從項目管理系統和ERP系統中同步過來。但是在流程圖中往往只會有採購訂單創建節點，因此容易遺漏這些基礎數據共享接口。
還有就是某一個業務功能在實現過程中，可能涉及到調用外部的業務規則和邏輯，這種交互點也容易遺漏需要特別注意。舉例來說，採購訂單在創建完成的時候並提交的時候需要檢查預算是否足夠，而這個檢查規則邏輯是預算管理系統實現的，因此在這裡也存在採購系統和預算系統間的業務接口和服務。
2. 自底朝上的服務識別
特別遺留系統環境進行SOA架構改造和服務接入的時候，我們要意識到必須要將遺留系統間的當前已有接口全部分析和梳理清楚。因為既然當前遺留系統能夠正常運作，也能完成跨系統的業務交互，那麼原來的接口從面上是完全能夠覆蓋業務需求的，我們唯一要考慮的是接口本身的定義和設計是否合理的問題。
當整理出完整的接口清單後，我們要做的就是搞清楚每一個接口對應的業務場景究竟是如何的？基於這種反向思路我們只關係和接口相關的業務交互場景，而不是關注全部業務流程。搞清楚了具體的業務場景後，接著要做的重點工作就是對接口進行評估，接口的評估主要包括了如下內容：
a) 接口當前使用頻度如何？是實時還是定時同步？同步頻率能否滿足業務的要求？b) 接口傳遞的數據量如何？當前在數據傳遞的時候有無性能問題？c) 接口本身的實現方法是如何的？比如Dblink，存儲過程，WS接口，還是直接原始的JDBC接口等。d) 接口本身的復用度如何？相關類似的接口有哪些？相互之間有哪些差異？
做了接口評估最主要的仍然是要考慮如何進行接口去重和接口合併，對於接口轉服務的方法，我前面有專門一篇文章再談，在這裡就不再展開。
本身相互獨立的兩個業務系統，比如A系統和B系統，按道理兩個系統應該完全獨立，包括資料庫，中間件，應用部署包等。兩個系統之間只能通過標準的接口進行業務和數據的交互。但是實際在項目實施中發現一種普遍存在的現象，即A系統將自己的資料庫帳戶完全開放為B系統，而B系統在拿到資料庫連接串信息後，通過自己編碼實現完全可以對資料庫A中的資料庫表進行各種任意的CRUD操作。
在這種情況下可以看到，A和B兩個系統之間已經完全耦合在一起，這個時候A系統要做資料庫層面的遷移和資料庫表結構的變更往往全部會影響到B系統。如果要把這些接口點找到，必須要把B系統中的所有代碼進行遍歷查找和分析，往往才能夠找到具體的接口點有哪些。這些不規範的使用方式都對後續的SOA服務改造和遷移造成相對重大的影響。
業務建模
業務建模包括了業務調研，業務流程分析，全局用例建模和全局數據建模幾個關鍵內容。其中核心仍然是基於業務流程驅動，基於流程分析來識別關鍵的業務用例和業務對象。
業務調研
該部分包括業務需求調研，包括業務流程或問題產生的背景介紹，具體的業務需求收集和分類。現有的業務流程現狀，業務需求所在的具體業務域，涉及到的崗位角色人員信息等。業務調研包括了業務流程，業務數據，業務系統三個方面的內容，業務調研內容具體輸出為業務調研文檔。
業務調研完成後應該輸出完整的業務流程調研報告，其中也包括了對業務系統間交互接口的調研和現狀梳理。
流程分析
流程分析需遵循端到端流程分析的思路，對流程進行二級，或三級分解。流程分析前可以先進行主題域分析，繪製上下文關係圖，通過上下文關係圖來進一步識別關鍵業務流程。具體參考流程分析指導書。
通過上下文關係圖對主題域進行分析後，可以得到主題域中所包含的業務事件，而這些業務事件就是業務流程的起點。流程分析時，需要注意流程的目標性、內在性、整體性、動態性、層次性、結構性這六大特性，流程是需求分析的重要內容，流程圖對於和用戶確認需求以及向開發團隊傳遞需求都是非常重要的。可以選擇使用UML規範中的活動圖或商業建模標準中所推薦的跨職能流程圖對流程建模。
通過流程分析可以進一步明確流程的的關鍵業務活動，每個業務活動的輸入，輸出，涉及的崗位角色，傳遞的業務數據等關鍵內容。具體流程分析輸出包括：
全局用例建模
根據業務域劃分和業務流程分析，進行用例的識別，流程中清晰地表達了角色所要執行的業務活動，這正是用例的內容，用例即用戶使用系統完成業務活動的場景在將業務活動及報錶轉換為用例後，使用UML中的用例圖對用例建模，用例圖不但可以表達出用戶是如何使用系統的，還可以表達出用戶與用戶之間的關係，用例與用例之間的關係。
對於流程圖轉換到用例的具體方法，可以參考需求分析指導書中的詳細說明和轉換原則。對於業務用例分析和建模基礎，請參考UML相關文檔。
全局數據建模
本部分主要是根據流程分析和用例建模，抽取流程和用例中的關鍵業務實體對象進行數據建模分析。全局數據建模只需要分析出關鍵的業務實體，實體描述和實體之間的關係即可，在業務實體建模環節講進一步對該部分內容進行細化分析。
全局數據建模需要輸出數據概念模型，數據實體對象清單和實體描述信息。
用例建模
用例建模
用例建模首先是流程建模中的關鍵業務活動會轉化為用例，這在全局用例建模中會進行分析。從流程圖中轉換用例時，先基於流程圖分析流程圖中的職能帶區(泳道)哪一些是不直接使用系統，將其排除，將餘下的職能帶區(泳道)轉為角色，將流程圖中的業務活動及判斷轉換為用例，決定活動是否要轉換為用例的標準是它是否屬於系統範疇，而決定判斷是否要轉換為用例的標準是它是否獨立。
用例建模需要參考用例編寫標準模板進行用例的編寫，針對每一個用例需要填寫的內容主要包括如下：
用例的編號，名稱，級別等信息。
用例執行的上下文背景介紹
用例執行的前置條件，後置條件，最小保證
用例執行的基本流
用例執行的擴展流
業務規則信息
假設和約束信息
其它備註或說明信息
業務操作分析
在用例建模的過程中，用例本身即是一個實現業務價值的交互業務活動集合。因此可以對用例進一步分析，識別更細粒度的業務活動和操作，這些業務活動或操作可以從基本流，擴展流和業務規則中尋找。業務操作分析要求如下：
業務操作即業務活動中的業務任務，有明確的業務含義
業務操作本身是可復用的業務單位
業務操作本身採用動賓結構進行描述
? 業務操作本身具有高內聚，鬆耦合性的自治性
數據建模
業務實體分析
用例模型只是對用戶如何使用系統的業務場景進行建模，如果要構建系統，還需要對系統的框架進行建模，即要弄清楚目標系統所要管理的「物」：業務實體，並弄清楚這些業務實體間的關係。
在對業務實體建模時，一般是使用「名詞動詞法」識別出業務實體，並逐步確定實體間的關聯關係及其屬性。
對業務實體建模選擇使用UML規範中的類圖或實體圖作為模型，類圖/實體圖中的一個類/實體表達一個業務實體，類/實體的屬性用於對業實體的屬性建模，而它們之間的關係則可以用來對業務實體間的關聯關係建模。對於比較複雜的業務實體，還可以採用UML規範中的狀態圖對其建模，可以表達出業務實體的狀態切換與觸發事件的關係。
業務實體分析中需要對識別的業務實體詳細描述業務實體的數據字典信息，包括業務實體中各個數據項的類別，長度，完整性規則，業務用途等相關信息。
實體使用U/C矩陣分析
實體使用分析主要包括業務實體跨系統使用情況分析和業務實體系統內使用情況分析兩方面的內容。
跨系統使用情況分析，主要是為公共數據服務的提取做準備，在該分析矩陣中需要列出業務系統產生的關鍵業務實體，分析這些業務實體在MSS域相關業務系統中的CRUD情況，作為後續數據服務識別的一個輸入。
業務實體系統內使用分析，主要分析系統內關鍵業務實體和業務用例之間的對應關係，找尋系統內可復用的業務操作，為系統內服務識別做準備。
服務識別
數據服務為以實現業務系統底層數據集成為目的，以業務實體為核心的數據對象傳輸為主的SOA服務。數據服務沒有明確的業務規則和含義。一般服務消費方在消費數據服務後都需要將數據同步到本地數據表，再根據業務系統自身需要對數據服務進行相關業務規則的封裝和實現。
01 業務實體確認
在業務建模和數據建模階段，已經對業務實體進行了分析，包括業務實體的類型，業務實體和業務功能的U/C矩陣分析等。業務實體是識別數據服務的基礎，因此需要對業務建模階段識別的業務實體進行確認。業務實體完全是業務視角的業務對象，而不是資料庫設計中的資料庫表，如採購訂單業務實體可能涉多層結構和多張資料庫表，但是在此處的分析只需要考慮採購訂單業務實體對象。
02 服務重用性分析
在業務建模構建的U/C矩陣的基礎上，可以從兩個層面分析服務的重用性。一個是跨業務系統的服務重用性，一個是在一個業務應用內部業務模塊間的服務可重用性。當一個業務主數據或一個核心業務單據需要跨多個業務系統或業務模塊使用的時候，則該業務實體識別為數據服務是可重用的。
03 服務實現方法分析
在服務實現的時候，一方面是考慮服務的可重用性，一方面是考慮業務敏捷要求。對於數據類服務一般可以實現為查詢類數據服務，也可以實現為導入類數據服務。當業務數據的業務敏捷性和時效性要求高時候，優先考慮實現為導入和分發類服務滿足業務敏捷性的要求。
04 服務大數據量傳輸分析
對於底層數據集成類服務，可能涉及到大數據量傳輸，這種數據對實時性要求不高，但是任何一個批次傳輸可能都在10萬級以上的數據量。對於這種情況要單獨進行分析，分析服務數據量，調用頻度，數據同步機制等。對於大數據量傳輸在識別為數據服務的時候可以考慮ODI服務，JMS消息，數據分頁等多種方式來實現。
業務服務識別
業務服務是有明確業務含義的，含具體業務規則和邏輯的，實現一個有價值的業務活動的一系列業務操作的組合。業務服務具有明顯的高業務內聚性，粗粒度特徵。
01 業務組件確認
業務組件是實現多個業務功能的，高內聚鬆耦合的業務功能模塊單元。業務組件是可以進行獨立需求分析，設計，開發，測試和部署的組件管理單元。
對於一個完整的業務系統或業務流程是通過業務組件的交互和協同來完成。業務組件之間的交互則通過標準的SOA服務方式進行。即業務組件中包含了技術組件和服務組件，其中服務組件暴露業務服務。
業務組件和服務的詳細關係如下：
1. 對SOA服務進行分析，可以從服務中發現組件。對服務進行組合、功能及UI界面封裝可以形成新的組件，所以組件可以調用一個或多個SOA服務，成為服務的消費者；2. 組件按照SOA服務識別規範，抽取服務，可以成為服務的提供者。
02 業務服務識別
對於業務服務識別分為兩個層面的內容。其一是為了實現跨業務組件的業務流程分析出來的業務組件之間的業務交互。其二是在用例建模階段我們對業務操作進行了詳細分析，對於這些分析整理出業務操作清單，對於業務操作清單中的可重用的業務操作識別為關鍵的業務服務。具體識別步驟為：
1. 根據業務流程或業務用例，繪製相應的跨業務組件協作的業務交互圖。2. 對所有的業務交互點識別為潛在的業務服務。3. 對業務操作活動列表進行分析，將可重用的業務操作識別為潛在的業務服務。
UI組件服務識別
UI組件是可以完成獨立的業務功能的小業務應用。UI組件可以獨立進行需求分析，設計，打包，部署和運行。UI組件是一種頁面內嵌的方式在多個業務系統中運行，因此在UI組件復用的情況下，基本不需要進行底層的數據集成和同步操作，可以更好的保證數據的一致性和時效性。
對於UI組件的識別主要分為兩個層面進行：
從頂向下識別：對於業務系統在構建中的業務系統和系統需求進行分析，在系統需求階段會進行詳細的功能需求描述和UI界面描述。可以針對這些需求文檔分析重複的業務功能界面，將其識別為潛在的UI組件服務。
從下向上識別：該方法是首先對業務系統中的平臺化功能模塊進行抽象，如工作流管理，系統管理，公共技術服務等都是可以進行平臺化的組件功能模塊。
對於平臺化的組件功能模塊需要和業務系統進行界面層的交互，因此對於這些界面層交互可以由平臺層提供UI組件服務內嵌到各個業務系統中使用。
技術服務識別
技術服務是和業務無關的，提供某種技術能力的服務。技術服務一般包括消息，安全，日誌，會話，規則，異常，資料庫管理等多個方面的內容。對於技術服務的識別仍然是包括了兩個層面：
從頂向下識別：在業務建模和業務系統需求分析過程中，需要關注業務系統非功能性需求的描述，這些非功能需求包括了異常，日誌，安全，性能，可靠性，高可用性，可擴展性，大數據量處理等多個方面的內容。對於這些非功能需求如果有多個業務系統或模塊提出，則可以考慮抽象識別為公有的技術服務。
從下向上識別：該方法是從平臺層面進行考慮，企業在業務系統建設過程中一般會分為產品層和平臺層，對於平臺層又包括了產品平臺和技術平臺。
在進行平臺化功能構建的過程中，平臺層需要朝產品層提供能力，這些能力的提供都可以考慮以技術服務的方式統一提供。以實現產品層和平臺層的集成。
流程服務識別
對於流程服務的識別，仍然是以前期輸出的端到端流程梳理和分析入手，以核心業務對象傳遞為基礎，梳理識別流程片段，將流程服務轉變為子流程和服務組合。流程服務的識別需要考慮服務的粒度，應以識別出來的流程片段本身也具備一定的服務價值為重要的衡量標準。