“顆粒度”問題
面向服務的設計一直都有一個話題，就是服務的“顆粒度”問題，無論是SOA還是微服務，都很難把握顆粒度。首先，SOA在實際操作中並不是真的關心顆粒度問題，一個遺留系統可以直接被封裝成一個服務，也可以把很小的功能服務化，二者地位是一樣的，所以，大家常說SOA本質上是個集成架構，有效解決了異構系統的集成問題，統一了內部通信方式，一般重擔會直接壓給企業總線。其次，微服務很關心顆粒度問題，但是卻很難判斷服務合適的大小，太大了，內聚性不好；太小了，通信會過於複雜，降低效率。近幾年，也有不少人用DDD方法指導微服務設計，取得了一些成果，但是DDD方法本身學習門檻比較高，不容易掌握。顆粒度還關乎另一個比較重要的話題，就是組裝式開發，之前介紹的業務模型方式是否能夠在這方面起到些幫助作用呢？
理論上來講，肯定可以，因爲業務模型的建模過程很注重標準化，標準化就是一個去重的過程，儘可能保證流程構成元素的唯一性，以免重複建設。但是任務這個層級對我們前邊討論的服務顆粒度劃分或者組裝式開發而言，“粗細”未必合適，它更符合業務視角的企業級架構設計，實現上我也介紹過，要對接到基於業務模型的分析設計方法上，通過活動、任務再走到用例、交易或服務的設計。組裝式開發是不是服務之間可以通信、互相調用就是組裝了？這樣的邏輯對於技術人員而言，好像可以接受，但是卻無法傳遞給業務人員，成了單純的技術組裝。另外，如果服務顆粒度劃分過細，這樣的組裝式開發也會累死通信機制，最後形成一個混亂的網狀通信，使得迭代、升級變得非常複雜。那麼如何在“粗”和“細”之間找到平衡方式，又容易被業務人員理解呢？這章開始，跟大家討論下改進的可能方法。
構件模型
可以在業務模型中再增加一個面向組裝式設計的表達，並通過這一表達形成面向業務實例或者產品的組裝式設計，這種方式至少在金融領域可以有效。設計邏輯如下：
這種設計一般應包含兩個目標，參數化配置和組裝式開發，前者好理解，就是一般項目上做的參數化設計，通過參數配置快速刷新產品，參數化設計對於代理保險、實物貴金屬、理財等標準化程度高的產品非常適用，因爲產品之間幾乎就是參數取值方面的差異，但是結合了後者之後，參數的設計就有了些變化。組裝式設計要求更強的結構化，面向產品時就要把產品切成“零件”，通過組裝“零件”、調整“零件”來快速實現新產品。那麼“零件”怎麼切呢？金融行業屬於服務業，金融產品就是金融服務過程，所以，金融領域中大部分產品其實跟流程是一體兩面的關係，將一段流程包裝起來銷售就成了產品，那產品的“零件”自然來自於流程。流程在業務建模時已經標準化成任務了，那麼再進行設計，自然就是針對任務進行調整，將一個“任務”再細分成若干個“零件”，亦或將多個任務聚合成一個“零件”，這些打破了任務結構的零件暫稱其爲“構件”。構件不像任務對應的是用例，而要對應服務的設計，一個構件可以由一個或一組服務組成，這取決於實際需要或者團隊的設計習慣。構件中的服務會涉及參數設計，這些參數都記錄在同一個構件上，嚴格來說這些參數應該都是數據模型中的屬性，可以在屬性上增加參數標識，以便從數據模型中容易識別出來。這些帶有參數的構件加在一起就形成了一個有結構的產品模板，既可以體現出組裝式設計，又可以用於參數配置。構件的切分原則應當是每個構件都能給出明確的業務含義，而不是單純爲了給服務分分堆兒。參數的選擇既可以定位在需要配置的參數，也可以更加寬泛地表達爲構件包含的服務的外部輸入報文集合和最終輸出報文，這樣更方便於構件的組合設計。
應用構件模型
構件模型與具體設計的結合如下圖所示：
設計上可以實現通過模板配置參數，實例化成業務實例或者產品；通過參數驅動動態界面；模板實例出的產品在預配和銷售中完成所有參數的賦值，服務運行時讀取賦值結果；基於構件與服務關係的服務清單可以用於服務管理和服務發現；合約關聯相應的賬戶，可以驅動賬務記錄。最爲困難和關鍵的是構件與服務之間的對應關係，下面我講講關於這方面的一些思考，由於本人設計經驗有限，權做與大家共同探討構件可行的設計方式吧。
舉個例子，涉及到競價的產品可能會有這樣的流程，即資金擁有方，比如總行，可以通過對某筆閒置資金進行內部的競價，從而確定出價最高分行可以運用該筆資金獲取收益，因爲競價決定資金歸誰使用其實是有機會成本的，因此競價過程中也可能需要通過計算EVA（經濟增加值）的方式，進一步衡量其經濟貢獻。通過下圖，我們把流程模型與數據模型相結合的表達、構件模型的表達與顆粒度較細的服務之間可能的關聯關係表示出來：
其中競價部分流程模型假定爲三個任務，數據模型簡化處理，設計四個數據實體。構件模型層面，競價任務可以獨立設計構件；從數據上看，意向申報和意向審批雖然按照角色會拆分成兩個任務，但是數據其實是一套，是可以合併設計的；EVA（經濟增加值）試算可以獨立，因爲其計算方式具有企業級的通用性，獨立有利於其他領域複用；競價、意向管理在實際業務中可能需要具有“可選性”，因爲有些產品是可以沒有這些流程的，所以，三個任務可以被設計爲三個“可選”構件。這樣拆分的構件顆粒度應該不會過細，並且支持業務含義的組裝。不過，如果服務層級設計的顆粒度過細，比如，例子中拆分成9個服務，這是設計中可能會存在的拆分方式，從實現上講可能沒毛病，但是維護、升級，特別是在業務理解上卻會比較麻煩。
從模型的角度講，構件仍然是邏輯的，要落實到服務纔是物理的，而服務的實現很多時候會依賴於開發團隊的設計習慣和經驗，對於大型企業級項目來講，如何在企業範圍逐步實現合理的顆粒度判斷原則是個難題，是要靠過程和溝通去逐步形成，良好的業務模型對於實現開發風格的一致性也是有幫助的。
例子中可以看到，構件打破了原來意向申報、意向審批這兩個任務的邊界，原來的流程，轉變爲了競價通知管理、意向管理和EVA試算三個構件的“組裝”，這三個構件相對獨立，每個構件可以進一步拆分爲更細的服務或者直接嘗試作爲一個服務設計。這樣的切分，最終會形成系統實現與模型之間最一致和最緊密的聯繫，也有點兒“微服務”的影子，並且，在日後的需求分析中會形成由需求直接定位到實現的能力。
到這裏，我總結一下：
首先，這種設計方式是一種可選的設計方式，也即，如果不做這種面向組裝的構件模型，只用之前介紹的業務架構方法，也足以實現企業級設計，做好參數化，也可以完成一定程度的靈活配置，只不過對於組裝式開發的表達有一定欠缺，這就要看企業希望實現的設計目標了。
其次，這種方法顯然難以在業務建模過程中，尤其是在企業初次進行企業級轉型，做最初的業務架構設計時一次性完成，也無法以業務人員爲主去做，有較多的系統分析與設計方面的考慮，更多是技術人員的工作範疇，因此，必須有技術人員深入參與，跟業務人員共同完成設計。雖然偏重技術，但是由於構件可以有明確的業務含義，完成首輪設計後，業務人員也能夠輕鬆使用這種模型與技術人員共同討論新需求，以及維護模型，特別是每個構件拆分的服務較少的情況下。
再次，這種模型可能打破原來流程模型中任務的邊界，產生新的模型表述方式，這種情況下，可以選擇是否將其視爲流程模型的一次新視角的迭代，替換掉原有的流程模型。這種模型打破了原來業務模型較爲單純的業務屬性，將業務含義與具體實現直接結合在了一起，而且是基於構件串起來的產品執行流程，是一種可以在一定程度上滿足流程與能力解耦的表達方式。雖然本文的討論側重金融領域，但是其他行業也可以找到適合自身特點的“零件”切分方式。這種方式也並非對本文前述方法論的較大顛覆，實際上只改動了對任務層面的表達，而活動層面並未發生變化，因此其從戰略延伸下來分解方式並未變化，而是在實施階段對業務模型的一次迭代演化，後續文章將進一步闡述這種設計可能的應用方式和好處。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基於企業級業務架構管理業務需求？
中臺之上（十）：業務架構設計“笨重”，它能跟敏捷沾邊嗎？
中臺之上（十一）：企業級業務架構設計的“五難”
中臺之上（十二）：如何快速設計業務架構？
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。