通用中台作为跨业务单元分散数据的事件驱动聚合点

业务单元化设计带来独立部署、独立团队的好处，但也天然制造了一个副作用：同一个客户在不同产品的投保业务单元里操作，产生的数据会被分散存储到各自独立的数据库中——用户买车险，数据存在车险投保业务单元；买意外险，数据存在意外险投保业务单元。如果没有额外设计，客户就无法在一个地方看到自己所有渠道、所有产品的进行中订单，”一体化销售体验”无从谈起。购物车这个通用能力中台承担的正是弥补这个副作用的角色：它并不修改各业务单元的数据归属和生命周期管理权（投保单的新增、修改、转保单等操作依然只在对应的投保微服务里完成），而是在每个投保业务单元生成投保单的那一刻，由该微服务发布一个领域事件，通过消息中间件把投保单的少量关键概要数据（ID、产品名、状态、保费等）异步同步进购物车；购物车按客户ID把这些概要数据集中起来，客户在任意渠道打开购物车都能看到自己所有未结算的投保单。这个模式的关键在于”数据集中”和”数据归属权”是分离的两件事：购物车只拿到了一份用于展示和结算的概要快照，投保单的完整明细数据和写权限始终留在原来的业务单元里，既解决了单元化设计带来的数据碎片化和体验割裂问题，又没有破坏各业务单元独立自治的边界。

结构图：

flowchart LR
  A1["车险投保业务单元<br/>(独立数据库)"] -->|"投保单已生成<br/>领域事件(异步)"| C["购物车<br/>(通用能力中台)"]
  A2["意外险投保业务单元<br/>(独立数据库)"] -->|"投保单已生成<br/>领域事件(异步)"| C
  A3["...其他产品投保业务单元"] -->|"投保单已生成<br/>领域事件(异步)"| C
  C -->|"按客户ID集中概要数据<br/>(ID/产品名/状态/保费)"| D["客户在任意渠道<br/>看到全部未结算投保单"]
  A1 -.完整明细数据与写权限仍留在原单元.-> A1