【微服務拔對上天堂，拔錯是災難】國泰中臺架構如何靠DDD找對設計方向

「拔對服務上天堂，但拔錯服務可是大災難。」即使完成了兩套中臺架構設計，國泰金控數數發中心首席企業架構師張維仁至今仍然覺得，如何抉擇，是設計微服務中臺最大的挑戰之一。

國泰金控以「技術轉型來輔助整體集團數位轉型」的戰略相當順利，近2年更是開始收穫過去幾年大力數位轉型的成果，去年技術年會中，更是大秀多項嶄新的金融商品、科技應用和內部作業革新。其中，最引人注目的就是全新保險商業模式「碎片化保險」。

國泰這個碎片化保險的商品顆粒度可粗可細，能細小到汽車上的一個車燈零件，保障期間可以更短，從開上高速公路到下交流道間的短短數小時，都能設計成一張保單產品。還可以提供高度多樣性能力，能夠按通路需求自由組裝成套餐。

不只產品面碎片化，對於內部業務團隊的產品開發上，也能分段多工進行，更大大縮短了新保險商品的開發時程，過去一款保單得花4個月，現在縮短到1個月，商品產量也從每月開發1支，提高到開發10支。

實現這個創新模式的關鍵是，由張維仁率領金控和產險技術團隊所打造出來的保險中臺新架構，這是國泰第二次中臺架構大改造的成果。

第一次是設計國泰世華銀行的中臺，採用了當紅微服務架構和容器化技術、K8s管理平臺，在傳統銀行資訊架構中，帶進了中臺設計的作法，後來更發展出了數據中臺和業務中臺。

銀行端這個新中臺架構上線後，運作得相當順利，國泰在2020年9月時揭露，透過中臺的單日交易量平均高達1,700萬次。

順利完成了銀行技術中臺設計後，國泰將銀行架構改造經驗，變成了一套架構改造範本，帶到了金控，進一步套用到產險領域，也就是保險中臺新架構，碎片化車險專案就是第一個業務場景的應用成果。

國泰將銀行架構改造經驗，變成了一套架構改造範本，帶到了金控，進一步套用到產險領域，也就是保險中臺新架構，碎片化車險專案就是第一個業務場景的應用成果。（圖片來源／國泰金控）

中臺架構最高原則是新舊融合

國泰所採取的中臺架構設計原則，「不是要用中臺來取代後臺大核心，而是利用中臺彈性，快速回應通路的蓬勃發展，又能串接原有的大核心系統。」張維仁解釋：「不是用新取代舊，而是用新技術包容舊技術，來形成一個新的架構，讓發展可以持續進行，這是國泰最重要的架構思想。」

在這個「新包舊」的原則下，最大的挑戰就是，那些原本在核心系統中的功能，拔出來改放到中臺，讓核心系統可以回歸基本面的帳務功能，專注於後臺處理的角色。

這的作法有點類似許多銀行近年陸續展開的「核心瘦身」、「小核心」等IT大改造，但不同的是，國泰是把從核心瘦身，拔出來的服務，放到微服務中臺。「怎麼拔」就是影響中臺架構能否成功的最根本的課題。

「如何正確地把服務從傳統核心中抽離出來，介接到中臺，國泰採用的方法就是DDD（Domain-Driven Design，領域驅動設計）。」張維仁透露了背後的關鍵，而且，這是國泰經過兩次中臺建置，才逐漸摸索出來的體會。

在 2018年，國泰在第一次銀行新中臺架構建置時，以技術中臺為主，當時還沒有發展出業務中臺的設計，也還沒有碰觸到非用DDD不可的後臺議題。

「國泰真正導入DDD的第一個實際專案就是車險，而且範圍不只中臺，還跨到後臺。」 張維仁回憶：「讓中臺架構、業務中臺和傳統大核心可以找出最大相容性、合作順暢的關鍵，就是DDD。」

一般DDD方法結合了敏捷專案作法，大多從使用者需求端出發，端到端的設計出全套流程，甚至常會先設計出使用者端操作界面的雛形後，再迭代開發出相關的商業邏輯程式和後端程式。

「從通路端的需求出發，用不用DDD沒有太大差別。」張維仁認為，或像是在銀行技術中臺設計時，單純聚焦技術，例如容器、ESB、API、微服務，當時不需要用到DDD也能進行。

但是，在車險專案中，架構設計必須進入業務場景，除了常見從通路前端需求發動，來思考後端架構的設計角度，「難道沒有從後到前的情況？」張維仁拋出了這個問題給架構團隊。

因為國泰同樣在產險資訊架構上，繼續沿用了「新技術包容舊核心」的策略，原本在產險核心系統就有許多業務流程和邏輯的設計，從後到前的改造途徑，第一個考驗就是得先拆解後端核心系統的業務，國泰產險資訊系統開發部同仁透露，這就是國泰發展「保險碎片化」模式在系統面的挑戰，不只有「拆解」，還要考慮如何「組合」。

國泰先透過四個途徑來拆解，由上而下，從通路端需求來思考、由客戶端需求來思考，再由下而上，從數據資料中找出可以價值化的服務，或是找出現有流程中可以共用的功能，來拆解出需要微服務化放入中臺的服務。

接著就是要解決「組合」的議題，張維仁指出，正確地拆解微服務，設定出微服務的邊界，可以找出一個相對合理的顆粒度尺寸，但這樣還不夠，還得解決如何找出對的服務（適合拔到中臺的服務）的課題，「就算是對的顆粒度，拔對或拔錯服務，就是天堂與地獄的差別。」

國泰金控數數發中心首席企業架構師張維仁表示，面臨一群架構的設計，涉及中臺、後臺、通路不同系統的組合，因為組合需求，放對或放錯非常重要，DDD可在事前提供一種「這個架構設計對了」的感覺，來協助服務定標、找對位置的信心。（攝影／洪政偉）

選定複雜場景，從事件風暴開始擁抱DDD

所以，國泰找來技術中臺開發人員和熟悉車險場域的後臺開發人員一起協作，嘗試用DDD來驗證，能否找出正確的業務邏輯切割和設計的途徑。國泰決定從車險專案，來舉辦DDD最常見的實作方法，也就是事件風暴（Event Storming）工作坊。國泰金控數數發中心雲端技術架構師顏勝豪表示：「國泰選定業務場景複雜，或者開發人員不容易理解的場景，來導入DDD。」

國泰金控數數發中心雲端技術架構師顏勝豪表示，國泰過去先導入DDD戰略設計，目前開始嘗試戰術設計方法，希望能將整個程式架構，都導入DDD方法論來切割。（攝影／洪政偉）

先找多角色共組讀書會自我學習

不過，在工作坊之前，還有一些準備工作。第一步是組成讀書會，國泰評估了幾本坊間常見DDD書籍後，大多過於艱深，後來挑了相對容易理解的Vaughn Vernon的《領域驅動設計精粹》（Domain-Driven Design Distilled）來閱讀。「這本書可讀性高，更搭配了一個實際的保險案例，剛好符合我們的場景。」顏勝豪這樣推薦。讀書會也找來資深技術架構師、企業架構師、資深領域專家、BA、SA、SD等一起參與，每周一次，每次兩人報告2個章節。不只有技術人員，加入了熟諳場景的資深人員，有助於從多面向引發討論。

顏勝豪比較，敏捷是一種軟體開發流程的方法，DDD是一種軟體分析設計的方法，而DevOps則是開發團隊和維運團隊彼此為對方多想一點的文化。DDD和敏捷一樣，都會透過工作坊，使用很多便利貼來討論，但是敏捷關注的是需求、缺陷、交付、團隊和開發團隊的管理，而DDD的目的是要通過業務抽象，來建立領域模型，維持業務和程式的邏輯一致性。

國泰如何舉辦事件風暴工作坊

2019年10月底某天，國泰正式舉辦事件風暴工作坊，選定的案例場景是線上購買金融商品。

由曾接受過DDD專業訓練，又熟悉保險領域知識的國泰金控數數發中心企業架構師高華志擔任工作坊教練。他設計了相關教材，涵蓋了事件風暴四大步驟，包括事件風暴、命令風暴、尋找聚合和再次探索。這個工作坊不只找來領域專家、技術人員也包括了需求單位的人員參與。

國泰這場工作坊中，第一個步驟是事件風暴，先由需求單位的領域專家進行業務流程說明，參與人員依據自身經驗和知識，將預期會發生的事件，逐一寫到橘色便條紙貼上大白板，這就是「業務流程貼標」的動作，接著進行事件排序，依據發生時間由左至右重新安排便條紙，並由領域專家檢視進行校正，達成共識後就完成了業務流程事件。

光是進行業務流程說明和事件風暴時，就開始了共通語言的設計，例如在這次車險工作坊中，技術人員與業務人員對名詞的認知會不一樣，例如套餐跟商品，訂單跟保單，都是不同的意義，商品是單一個產品，而套餐則是給使用者的一套保險，或者領域專家認為，訂單就等於保單，但從技術角度來看是兩種不同的概念，因為中間還有一個Kafka防火層設計。

傳統軟體開發方法，從使用者提出需求，SA設計需求文件，再由SA設計系統規格，最後交給開發者，高華志解釋，開發人員永遠都離需求很遠，原始業務需求經過3次翻譯，若每次損失2成細節，訊息遞減的結果，最後開發出來的系統就會少了一半的內容。

但是，高華志表示：「導入DDD方法論，將多個單位集中一起進行工作坊，讓大家彼此的認知有一致性，有共通的語言，這個語言就是領域語言。」另外，他還建議，DDD設計共通語言時，盡量用英文，好處是設計程式碼時，工程師可以直接沿用，不用想命名。

第二步驟是進行命令風暴，這個階段的目的是找出產生事件的命令，以及執行命令的相關概念實體，針對命令風暴任何一個程序，參與者共同討論，找出更細節要執行的命令，並且定義出會觸發這些命令的用戶和外部系統。同樣寫到便條紙上，來進行貼標後，再次進行排序，也由領域專家檢查確認做最後的校正，得到共識版本。舉例來說，進行相關商品時，是否需要呼叫外部系統進行通算，查詢理賠記錄。

接著是關鍵的第三步驟「尋找聚合」，將白板上的相關命令和事件，以領域概念來進行分組，並且尋找聚合關係，用白板筆畫線圈出同一類的便條紙，讓聚合關係更視覺化。DDD有三種領域概念，包括了核心域、通用域和支撐域，來區分服務的三種屬性，例如若要打造一套共用服務，可以將具有通用域或支撐域屬性的事件，歸類到這一個領域下。成員還是要再進行討論和確認，最終產出「聚合模型」

最後一個步驟是持續探索，參加者從完成的聚合模型中，開始識別出有效的界限，並探索上下文關係（Upstream或Downstream），來定義上下文的屬性，持續討論調整達成所有成員共識，產出一份界限上下文關連圖。聚合的一種作法是，從資料的上下游流程關係來分上下游關係，定義資料從這個部分，流向另外哪一個部分。最後討論出有共識的上下游關連圖，也就成了國泰設計中臺微服務拆分時的初步參考流程，但不是最終定案版，還可以不斷修改。張維仁指出，有了這個上下游關連圖，就容易思考，什麼服務與核心的相關性更高，有助於判斷什麼服務適合拔出去。

第一線開發團隊的國泰產險資訊系統開發部同仁表示，事件風暴完成的最後那一張圖，可以提供一個圖像化結構的方式，讓架構師建構出一個對整體系統的全局觀，有助於在事前設計時，更清楚要將什麼服務該放到哪一個適當位置，判斷該放入核心或中臺。不過，這也只是初步參考，最後還要靠實際開發和上線成果來驗證。

國泰這場事件風暴工作坊用了一整個下午的時間，還有不少事前準備，例如各參與者得事先思考業務流程的需求和事件。擔任工作坊教練的高華志提醒，不要一次全面導入DDD，先挑選重要的領域著手。

另外，這次指導工作坊流程運作的教練，不只熟諳DDD，同時也是保險的領域專家，高華志坦言，還不確定兩種角色分開後，能否順利進行，國泰目前先訓練出具備雙重角色的教練。

可以強化事前「架構設計對了」的信心來協助服務定標

從架構設計的大格局來看，張維仁總結，為了單一系統採用微服務設計，DDD的幫助可能有限，因為顆粒度大小不影響這個單一系統的運作，可是當面臨了一群架構的設計，而是涉及各多個不同系統，包括了中臺、後臺、通路的組合，因為「組合」需求，放對或放錯就非常重要，DDD可在事前提供一種「這個架構設計對了」的感覺，來協助服務定標、找對位置的信心。

從讀書會開始自我學習，實際落實到專案來嘗試，也找來外部專家參與討論，2020年底更把導入經驗也投稿到研討會，跟業界專家交流。顏勝豪表示：「過去只採用了DDD戰略設計的部分，目前則開始嘗試戰術設計的方法，希望能將整個程式架構，都導入DDD方法論來切割。」

國泰DDD導入一方面導入方法論，同時展開從車險展開第一個導入實作。張維仁期待，經過幾次實作嘗試，就可建立信任度，找出服務正確切割，安排到正確位置的一套方法，「國泰已經有了第一步的順利嘗試，後續還要用更多專案來驗證。」