【微服务拔对上天堂，拔错是灾难】国泰中台架构如何靠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导入一方面导入方法论，同时展开从车险展开第一个导入实作。张维仁期待，经过几次实作尝试，就可建立信任度，找出服务正确切割，安排到正确位置的一套方法，“国泰已经有了第一步的顺利尝试，后续还要用更多专案来验证。”