作者在《保险趋势分析与保险中台数字化转型》文章里提到了保险业务系统中台化后保险商品化和订单化的销售模式，本文主要通过购物车、订单中心、微前端以及产品通道等技术手段，对保险企业实施中台战略后的保险订单化销售模式进行设计，形成可实施的方案。微前端相关技术文章详见《中台微服务了，那前端呢？》。
随着5G技术的应用，人们的消费方式将进一步移动化和线上化。电子商务交易中最重要的维系双方契约的凭据就是订单。订单化销售模式是目前最通用的电商销售模式。而保险由于各种原因，现在主要通过保单的方式进行产品的销售。
随着电子保单的使用，保险公司与客户之间交互的环节将变得更简单。保险流程虽然复杂，但通过保险产品、业务流程和技术方案设计，也可以具备便捷的订单化销售能力，让用户在购买保险产品时也能与购买电子商务商品一样，有一致的体验。
对于保险集团而言，为充分利用销售资源，实现集团一体化的综拓销售和所有子公司保险产品的一体化交叉销售，需对所有产品实现无差异的一体化运营和销售。
传统的保险核心业务系统基本都是分险种建设的，前端没有统一的操作界面，客户在购买多个保险产品时很难享受到流畅的服务。
以产险为例，承保核心系统基本是以车险和非车险产品为边界建设。由于前端页面分离，没有统一的销售界面，用户只能在一个系统内进行竖井式操作，一次只能完成一类产品承保。如产品涉及车和非车险，则需要分别操作车险和非车险两个系统才能完成承保。
同一公司内跨车和非车险产品销售存在体验的问题，如果把产、寿、健和养老所有子公司保险产品放在一起统一运营和销售，面临的问题就更复杂了。
为了解决所有保险产品无差异一体化销售的问题，可以借鉴电商订单化的销售模式，在保险产品之上增加一个实体，这个实体就是订单。
在前端，利用前端集成主页面通过商品、录单、购物车、订单、保单管理等业务功能建立所有产品的客户接触和体验的一体化销售界面。
在后端，订单实体分别协同后端不同类保险产品的承保专属业务中台，异步完成后端的业务流程，实现系统之间的彻底解耦，降低系统实时处理压力。
订单销售模式
保险订单销售模式可以满足跨多个保险产品复杂场景的产品无差异的一体化销售目标，给客户提供一致的体验，满足集团化或者保险商城等多产品组合销售场景要求。同时还可以通过事件驱动的异步化的模式，彻底解耦后端应用，降低实时处理压力。
既然销售要线上化，那就用线上的Style去购买保险商品！
通过订单化的销售模式，让客户以电子商务熟悉的流程和方式购买保险产品，提升用户的体验。
在本节引入两个新概念：微前端和产品通道。
先来解释一下什么是微前端？微前端是ThoughtWorks2016年提出来的，它将微服务理念扩展到前端开发，在前端同时构建多个可以独立部署、完全自治、松耦合的页面组合，其中每个组合只负责特定的 UI 元素和功能。通过前端页面集成组件根据产品和业务环节动态加载微前端页面，完成全部业务流程。
微前端理念最初的出发点是：中台微服务化后，微服务所对应的前端页面仍然采用单体模式，为了降低前台逻辑的繁杂和臃肿，因此按照一定的规则将前端页面进行拆分。微前端方式除了可以实现前端页面的解耦外，还可实现前端页面逻辑的复用，做到“一次开发，多端复用”，这也与中台的服务共享理念是一脉相承。
做前端设计时可以借鉴微前端设计理念，将可共享的前端页面改造成微前端。如为承保专属中台投保微服务，建立保单录入微前端。保单录入微前端与投保微服务两者协同完成保单录入操作。
适配不同终端的微前端，经过简单配置就可以快速加载到PC端、APP以及智能终端等各个前端集成框架中。集成后端业务逻辑的微前端，无需再次开发即可实现复用。
微前端复用主要包括两类场景
1）单一产品销售场景：同类产品微前端可独立部署，稍加调整即可作为APP或者直接作为web应用进行发布，极快响应单一产品销售场景的业务要求。
2）组合产品销售场景：不同类产品微前端可根据业务路由规则，快速加载到PC、APP、智能终端等前端集成框架，进行多产品组合销售。
微前端设计要点
1）所有微前端有统一的界面风格。
2）可根据保险商品和流程动态加载商品对应的微前端页面。
3）微前端和专属中台微服务由一个团队开发，微前端已与中台微服务集成，两者配合可以独立完成本产品领域内操作。
4）同类产品专属业务中台的投保和保单管理微服务有录单和保单管理微前端，作为录单和保单管理操作界面。
由于不同的保险产品面向不同的场景，解决的问题不同，在录单要素、业务规则以及流程等方面存在较大的差异，因此不同类的保险产品其领域模型也会存在不同。为了避免不同类产品之间的相互影响和干扰，在进行承保业务中台设计时，建议以同类型相似场景的保险产品作为聚合进行承保专属业务中台的建设，而不是简单的以车险和非车险两类产品作为边界建设。
什么是保险产品通道？保险产品通道是为了后续讲解方便定义的一个新名词。
保险产品通道包括保险产品所在的微前端、承保业务中台以及业务中台后端对应的收付费、佣金、再保等通用能力中台和客户统一视图和业务统一视图等数据中台。同类产品在这个通道内完成录单、投保、保单生成、退保、批改以及向后端送数等操作。保险产品通道主要隔离点在微前端和不同产品的承保业务中台。同类产品使用同一个产品通道，不同类产品使用不同的产品通道，所有流程无交叉，功能相互隔离。
借助客户、用户、订单、核保和支付等通道外的通用中心，从录单、投保到保单管理等流程在产品对应的微前端和承保中台的通道内自包含完成。生成保单后的后序业务流程根据业务规则异步自动触发，多个产品通道通过各自业务中台的保单管理微服务将数据异步汇集到后端收付费、佣金、再保等通用能力中台以及客户统一视图和业务统一视图等数据中台（如下图）。不同类产品后端接收数据的中台可能会不一样，如寿险专属业务中台会将数据送到寿险子公司的后端，财险专属业务中台会将数据送到财险子公司的后端，数据传输逻辑已在各自专属业务中台保单管理微服务中完成。
微前端、业务中台和产品通道
产品通道设计要点
1）承保流程中不同保险产品通道之间无交叉和交互。
2）同类产品承保业务流程在自己专属产品通道内完成。
产品通道的意义
1）业务专一性：领域模型更聚焦，功能更单一，前后端项目团队规模更小，集中办公，更专注于本领域内的业务逻辑和微前端。产品通道业务高度内敛，同类产品录单、流程和规则基本相似，不包含不同类产品的要素，产品之间干扰小，用户体验会更好。
2）职责专一性：由于产品通道完成了从前到后的全部流程，专职于产品中台业务逻辑和微前端页面的实现。因此谁负责产品，谁就负责微前端和业务中台全通道业务逻辑的开发。前端集成项目只需完成微前端的集成即可，集成过程甚至都不需要API层面的集成，减轻前端集成压力和界面开发的复杂度。尤其对于集团级跨子公司（主要问题是系统和业务相互不熟悉，接口和集成复杂，沟通成本高）的系统集成会带来极大的好处，降低沟通成本和集成的复杂度。
3）复用性：微前端和业务中台都有高度的复用性。微前端只需在商品目录中完成URL地址配置即可快速加入前端集成框架，或将微前端直接发布到APP等，实现快速发布。某些场景甚至一个微前端就是一个应用，直接可以完成一类产品的出单。
4）隔离性：同类产品的逻辑代码的修改都被控制在一个产品通道内，不会影响任何其他产品通道的业务。不同产品通道内各层代码的发布以及新产品通道的上线相互隔离，通道之间不受影响。
5）响应能力：新型产品只需新增商品目录和添加微前端地址即可快速完成上线。已有产品通道只需要在前端集成框架内加载微前端URL地址就可以完成业务发布。
6）可配置性：商品目录中配置产品微前端地址，前端集成框架根据配置的微前端URL，加载微前端。
7）沟通成本低：一个产品通道由一个项目团队完成，沟通和测试成本低。
由于不同保险产品领域模型的差异，建议以同类和相似场景的保险产品（如车险类、意外类、财产类、货运类、寿险类、健康类等）进行功能聚合完成承保业务中台建设。承保业务中台至少应包含投保和保单管理两个微服务，每个微服务对应一个微前端。
承保业务单元（含数据库、中台和微前端）
按照上述思路，集团内N类产品将会有N个承保业务中台，每个承保业务中台至少包含：投保和保单管理两个微服务。
投保微服务主要存储客户接触过程中的投保数据和处理投保业务逻辑。配合核保中心完成核保操作，订单支付完成后，订单中心通过事件机制触发投保微服务将投保单转成保单，并异步将数据传送到保单管理微服务和客户统一视图。
保单管理微服务异步接收从投保微服务将投保单转保单后的保单数据。异步传送后续流程需要的数据，如：佣金、收付费、再保以及客户统一视图库和业务统一视图数据。
中台项目在建设投保和保单管理微服务时，需同步建设并集成录单和保单管理微前端，微前端分别完成录单和批改、退保的页面逻辑。
前端集成主页面集成所有微前端页面，实现所有微前端的聚合。按照正确的逻辑（如根据客户选择产品，选择加载产品对应的录单微前端，完成录单和投保）加载微前端页面，协同配合完成完整的业务流程，给用户提供一致的体验。
前端集成主页面和所有微前端须有统一的页面风格，且符合前端的集成技术规范。
前端集成主页面加载并组合各微前端，作为一个整体为客户提供所有保险产品销售的接触和体验界面，包括商品展示、录单、购物车、订单管理、支付管理以及退保和批改等保单管理操作。
以投保和保单管理为例，说明前端集成主页面的工作原理。
1）在录单过程中，客户选择保险产品，前端集成主页面根据客户选择的保险产品，获取产品对应的录单微前端路由，也就是录单微前端URL地址，在主页面指定区域加载录单微前端页面。录单微前端负责录单界面，投保微服务负责投保单生成等后端逻辑，两者配合在产品通道内完成投保单的录入和投保单生成。
2）在保单管理过程中，前端集成主页面根据客户选择的保险产品加载产品对应的保单管理微前端，两者配合在产品通道内完成保单退保或批改。
实现保险订单化销售需要建立标准的保险商品目录，并将商品目录数据前推到前端应用。
1、保险产品需要形成标准的保险商品目录，为客户提供统一的商品展示，保险商品目录信息存储在保险商品配置中心（如Redis），商品目录数据应包含：产品基本信息、条款以及产品微前端URL以及API地址等内容。
2、产品路由信息包括产品对应的投保和保单管理微服务所对应的微前端URL地址和保险产品专属业务中台API地址。选择完产品后，前端集成页面可根据URL地址加载微前端页面URL完成录单。投保单生成后，订单中心可根据产品API路由访问专属业务中台API。
3、保险商品目录信息由产品中心统一配置，推送到所有与产品销售相关的前端应用。
4、保险产品专属业务中台应提供标准统一的API服务，可根据产品自动适配，减少不必要的开发和集成。
在原有保险应用的基础上，新增两个中台应用：订单中心和支付中心，并在前台应用中增加购物车功能。
购物车主要用于暂存投保单的清单数据，清单数据可存储在前端缓存（如Redis）中。投保单的明细数据存储在投保微服务所在数据库中。
订单中心是前端应用和业务专属中台的桥梁。前端应用、购物车和订单中心一起为客户提供统一的产品销售和接触服务，订单支付完成后由订单实体协同保单实体完成异步流程。
支付中心提供面向订单的统一支付服务，订单支付完成后，通知专属业务中台投保微服务完成转保单操作，转保完成后订单中心将所有与订单关联的保单置为生效状态。订单中心保存保单的清单数据，保单明细数据保存在保单管理微服务数据库中。
统一说明：以下时序图暗红色线条为实时操作，蓝色线条为异步操作。
商品目录是订单销售模式一个重要的点，商品目录需提供保准的保险产品描述、条款等基础数据，因此需要设计一个标准的保险产品模型。
借用大家都熟悉的面向对象的设计方法来解释一下保险产品模型。我们在定义一类对象的时候，通常首先需要先定义一个抽象的Class类，这个Class类中定义了这类对象的属性和方法，在执行过程中Class类会实例化成对象，根据不同的对象给属性加载不同的数据，根据不同的数据输入计算出不同的结果。
映射到我们的保险产品体系中，这个Class就是保险产品模型，而对象对应根据保险产品模型加载业务信息后的保险产品。通常保险产品包含：保险的基础信息、条款、报价规则、佣金规则等信息。保险的基础信息和条款等内容属于静态信息，可以认为是Class里对象的属性，而保费计算以及佣金计算等可以认为是Class里对象的方法。为建立标准的保险产品体系，首先需先定义标准的保险产品模型，再针对具体的保险产品赋予相应的属性和业务规则。
为了保证产品领域模型的完整性，产品中心可集中定义产品所有的通用描述信息、条款等属性信息以及通用的保费和佣金等计算规则，实际计算和业务流程可在产品所在业务中台（如报价、佣金等）内完成。
产品中心是一个后端集中的配置中心，产品通用配置数据在产品中心内中完成，个性配置数据可在中台和前端应用自行配置。产品中心不参与实际的业务流程。在完成产品通用信息和规则配置后，将数据异步发送到对应的业务中台和前端应用完成产品相关的业务操作。
产品中心配置数据推送时序图
主要业务流程说明
1）在产品中心完成产品数据配置（含新增以及变更）。
2）产品基础数据和条款等基础配置数据异步发送到商品目录缓存。
3）通用定报价规则和配置数据异步发送到报价中心。
4）通用佣金计算规则和配置数据异步发送到佣金系统。
投保流程涉及到保险商城（由前端集成框架实现）、商品目录、产品通道中的录单微前端和投保微服务、报价中心、购物车以及投保单视图的客户统一视图等几个功能。
投保单生成
主要业务流程说明
1）保险商城从商品目录中加载保险商品清单。
2）客户选择保险商品。
3）保险商城根据客户选择的保险商品，从商品目录中获得该产品的录单微前端URL地址，并加载到保险商城的指定区域。
4）客户在录单微前端完成投保单录入，提交投保单微服务，生成投保单，调用报价中心API完成保费计算。
5）投保单微服务向保险商城返回投保单基础信息和保费数据。
6）客户在保险商城将投保单加入购物车。
7）如需购买其他产品，重复1-6步骤。
设计要点
1）录单微前端URL地址与产品配对，存储在保险商品目录缓存中，前端选择完产品后，由前端集成框架将微前端页面加载至指定区域。
2）投保单清单数据存储在保险商城的应用中用于前端展示。投保单明细数据存储在投保微服务数据库中。
3）投保单生成后，投保单一部分清单数据会异步发送到客户统一视图数据库中，任何渠道都可查询到客户未生成保单的投保数据。
核保环节涉及到投保微服务和产品对应的核保中心。在购物车中选择多个核保通过的投保单，生成订单，一次完成订单关联的所有投保单保费支付。订单支付环节涉及到订单中心和支付中心。
核保与订单支付
主要业务流程说明
1）客户从购物车中选择多个投保单，一次提交核保，向产品对应的核保中心发起核保申请（包含投保单概要信息）。核保流程也可在投保过程中完成，设计时可根据具体情况考虑。
2）如商品免核保或自动核保，则直接返回核保结果。
3）如需人工核保，核保中心根据商品投保单号，从投保单微服务获取投保详细信息，完成核保，返回核保结果。
4）客户从购物车中选择多个核保通过的投保单，生成订单。
5）提交支付中心，一次完成订单关联的所有投保单支付。
设计要点
1）从保险商城通过队列向核保中心异步提交核保，核保完成后核保中心通过队列向保险商城异步返回核保结果（监听模式）。
2）在商品目录中配置产品对应的核保中心API地址。
3）生成订单后，订单实体需关联所有投保单号，并存储投保单的清单信息，用于前端展示。
4）对于时间较久的订单和投保单，提交支付前前端需要核验所有投保单的保费计算和核保结果是否在有效期内，如果超过有效期，需要重新计算保费和核保后才能支付。
5）所有产品都是在自己的产品通道内并发进行。
支付完成后的主要流程为异步操作。
保单生成操作主要涉及投保微服务和保单管理微服，保单号在投保微服务中生成，通过事件驱动机制异步将保单数据发送到保单管理微服务。
后续流程涉及到佣金、再保、收付费以及客户统一视图，也主要采用异步方式。
保单生成和后续内部管理流程
主要业务流程说明
1）订单支付完成后，由订单实体通知各产品通道中的投保微服务生成保单。
2）投保微服务收到转保单通知后，将投保单转保单，并关联保单号。转保单后投保微服务有三个异步操作：（1）通知订单中心已完成转保单操作，同时将保单清单数据返回订单中心；（2）将保单明细数据异步发送到保单管理微服务；（3）通知客户统一视图，修改投保单状态（标注已转保），并关联保单号。
3）订单中心收到转保成功和保单基础数据后，将订单实体与所有保单关联，保存保单清单数据用于前端展示。
4）保单管理微服务收到保单明细数据后，将保单数据保存在数据库中，异步发起送佣金、再保、收付费和客户统一视图动作。
设计要点
1）由于后端业务逻辑比较复杂，为了实现解耦，本部分的大部分操作都是采用事件驱动的异步化方式进行的。
2）对于优惠的场景，订单根据整单保费和优惠规则，在订单内对保费进行重新计算和分配，并将重新计算后的保费数据保存到保单中。保单保费信息将有两个字段存储：标准保费和优惠后的保费。
3）如不存在优惠的情况，标准保费和优惠后的保费数据相同。
4）按照优惠后的保费数据完成异步送数。
5） 所有产品都是在自己的产品通道内并发进行。
客户的一致性体验主要通过客户统一视图来实现。前端应用每生成一份投保单和保单都会与客户ID关联，并分别存储在投保单视角和保单视角的客户统一视图库中。
投保单视角的客户统一视图主要存储跟客户投保相关的所有渠道的投保数据，以客户维度作为分库主键。客户投保时可以看到自己任何渠道产生的未转保的投保单数据，可以以此为基础继续完成投保操作。后续过程中任何渠道投保单如果已转保，都通过异步的方式，修改客户统一视图中的投保单数据，保证数据的一致性。
保单视角的客户统一视图主要存储客户所有渠道的保单数据，以客户维度作为分库主键。客户在通过统一视图可以看到自己在集团内所有子公司各个渠道生成的保单数据。保单视角的客户统一视图数据可以为后续批改、退保和续保等流程提供保单查询服务。保单数据的任何修改都在产品通道的保单管理微服务中进行的，任何渠道对保单数据的修改都需通知客户统一视图修改，保证客户保单数据的一致性。
保单管理的退保和批改可以从前端订单中发起，通过订单找到关联保单，统一由保单管理微服务完成保单管理业务。
也可以通过客户统一视图或者保单库的查询找到保单后在后端直接发起，统一由保单管理微服务完成。
根据具体的场景选择合适的方式，必须确保所有的操作都在自己的产品通道内完成。详细流程本文不再赘述。
1、订单化的销售模式有利于集团级的产品无差异的一体化销售，提升客户体验。
2、微前端和产品通道的模式从前端页面到中台服务可以实现全面复用。
3、利用微前端可在前端实现拼图式开发，通过微服务可在中台实现积木式开发。
4、产品通道的模式可实现产品级拼图式快速集成。
5、产品通道的模式可以让前端集成人员不必关心产品技术实现。
