今天整理和分享下流程驅動的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元件服務內嵌到各個業務系統中使用。

技術服務識別

技術服務是和業務無關的，提供某種技術能力的服務。技術服務一般包括訊息，安全，日誌，會話，規則，異常，資料庫管理等多個方面的內容。對於技術服務的識別仍然是包括了兩個層面：

從頂向下識別：在業務建模和業務系統需求分析過程中，需要關注業務系統非功能性需求的描述，這些非功能需求包括了異常，日誌，安全，效能，可靠性，高可用性，可擴充套件性，大資料量處理等多個方面的內容。對於這些非功能需求如果有多個業務系統或模組提出，則可以考慮抽象識別為公有的技術服務。

從下向上識別：該方法是從平臺層面進行考慮，企業在業務系統建設過程中一般會分為產品層和平臺層，對於平臺層又包括了產品平臺和技術平臺。

在進行平臺化功能構建的過程中，平臺層需要朝產品層提供能力，這些能力的提供都可以考慮以技術服務的方式統一提供。以實現產品層和平臺層的整合。

流程服務識別

對於流程服務的識別，仍然是以前期輸出的端到端流程梳理和分析入手，以核心業務物件傳遞為基礎，梳理識別流程片段，將流程服務轉變為子流程和服務組合。流程服務的識別需要考慮服務的粒度，應以識別出來的流程片段本身也具備一定的服務價值為重要的衡量標準。