业务中台的数据架构设计——数据域划分、服务边界与共享模型-港品优选

业务中台的数据架构设计——数据域划分、服务边界与共享模型

一、中台建设的核心挑战

业务中台的概念提出多年，但真正落地成功的案例并不多。大多数失败的中台项目，根源不在于技术选型，而在于数据架构设计不当——服务边界模糊、数据域划分混乱、共享模型缺乏治理。

我们团队在过去两年里主导了一个电商业务中台的建设，覆盖交易、商品、库存、营销、会员五大核心域。这个项目让我深刻认识到：中台的数据架构设计，本质上是在"复用"和"隔离"之间寻找平衡点。复用过头会导致服务耦合爆炸，隔离过头会导致重复建设和数据不一致。

二、数据域划分方法论

数据域划分是中台数据架构的起点。我们采用"业务能力+数据生命周期"双维度来定义数据域边界。

划分原则：

高内聚：同一域内的数据实体变更频率和业务规则高度相关，应该被同一个团队负责
低耦合：跨域的数据依赖只能通过服务接口实现，禁止直接访问对方数据库
独立演进：每个域的数据模型可以独立变更，不影响其他域的业务功能

三、服务边界定义

数据域划分完毕后，需要将每个域拆分为一个或多个微服务。服务拆分的粒度决定了系统的灵活性和复杂度。

/** * 库存域中的数据聚合服务——通过编排多个子服务提供统一视图 * * 设计原则： * 1. 跨子服务的查询通过聚合实现，不通过数据库JOIN * 2. 每个子服务维护自己的数据，通过事件异步同步必要信息 */ @Service public class InventoryAggregationService { private final PhysicalInventoryService physicalService; // 实物库存服务 private final ChannelInventoryService channelService; // 渠道库存服务 private final InventoryLogService logService; // 库存流水服务 public InventoryAggregationService( PhysicalInventoryService physicalService, ChannelInventoryService channelService, InventoryLogService logService) { this.physicalService = physicalService; this.channelService = channelService; this.logService = logService; } /** * 获取SKU的全渠道库存视图 * 聚合实物库存和渠道库存，提供统一的外部查询接口 */ public SkuInventoryView getSkuInventoryView(String skuCode) { try { // 并行查询各子服务，提升响应速度 CompletableFuture<PhysicalInventory> physicalFuture = CompletableFuture.supplyAsync(() -> physicalService.queryBySku(skuCode)); CompletableFuture<List<ChannelInventory>> channelFuture = CompletableFuture.supplyAsync(() -> channelService.queryBySku(skuCode)); // 等待子服务返回，设置超时防止雪崩 PhysicalInventory physical = physicalFuture .get(500, TimeUnit.MILLISECONDS); List<ChannelInventory> channels = channelFuture .get(500, TimeUnit.MILLISECONDS); // 组装聚合视图 return SkuInventoryView.builder() .skuCode(skuCode) .physicalInventory(physical) .channelInventories(channels) .totalAvailable(channels.stream() .mapToInt(ChannelInventory::getAvailableQuantity) .sum()) .build(); } catch (TimeoutException e) { log.error("库存查询超时, skuCode={}", skuCode, e); throw new ServiceException("库存服务暂时不可用，请稍后重试"); } catch (InterruptedException | ExecutionException e) { Thread.currentThread().interrupt(); throw new ServiceException("库存查询异常", e); } } }

四、共享数据模型治理

中台最大的挑战之一是对共享数据模型的管理。不同业务线对同一数据实体（如"商品"）的理解和使用方式可能完全不同。我们采用的策略是：核心属性统一管理，扩展属性业务自治。

/** * 商品域核心模型——定义跨业务线共享的基础属性 * * 设计约束： * 1. 核心属性的变更需要所有消费者评审 * 2. 扩展属性由各业务线自行管理，存储在独立的JSON字段中 */ @Entity @Table(name = "t_product_base") public class ProductBase { /** 商品SPU编码（全局唯一） */ @Id @Column(length = 32) private String spuCode; /** 商品名称（核心属性，统一管理） */ @Column(length = 200, nullable = false) private String productName; /** 商品类目编码（核心属性） */ @Column(length = 20, nullable = false) private String categoryCode; /** 品牌编码（核心属性） */ @Column(length = 32) private String brandCode; /** 计量单位（核心属性） */ @Column(length = 10) private String unit; /** 业务线扩展属性（JSON格式，各业务线自治） */ @Column(columnDefinition = "jsonb") private String extendedAttributes; /** * 获取指定业务线的扩展属性 * @param bizLine 业务线标识（如"fresh_food"/"digital"/"fashion"） * @param clazz 扩展属性的目标类型 */ public <T> T getExtendedAttribute(String bizLine, Class<T> clazz) { try { ObjectMapper mapper = new ObjectMapper(); JsonNode root = mapper.readTree(extendedAttributes); JsonNode bizNode = root.get(bizLine); if (bizNode == null) { return null; } return mapper.treeToValue(bizNode, clazz); } catch (JsonProcessingException e) { log.warn("扩展属性解析失败, spuCode={}, bizLine={}", spuCode, bizLine, e); return null; } } /** * 更新指定业务线的扩展属性（业务线自治） */ public void setExtendedAttribute(String bizLine, Object attributes) { try { ObjectMapper mapper = new ObjectMapper(); JsonNode root = extendedAttributes != null ? mapper.readTree(extendedAttributes) : mapper.createObjectNode(); ((ObjectNode) root).set(bizLine, mapper.valueToTree(attributes)); this.extendedAttributes = mapper.writeValueAsString(root); } catch (JsonProcessingException e) { throw new DataModelException("扩展属性序列化失败", e); } } }

五、数据一致性保障

跨域的数据一致性是中台架构中最棘手的问题。直接使用分布式事务（如Seata AT模式）虽然简单，但会引入性能瓶颈和耦合风险。我们选择了基于事件的最终一致性方案。

/** * 订单创建事件处理——跨域数据同步的核心机制 * * 业务场景：订单创建后，需要扣减库存（库存域）和冻结优惠券（营销域） * 通过领域事件异步通知，各域独立处理，通过本地事务保证数据一致性 */ @Component public class OrderCreatedEventHandler { private final InventoryClient inventoryClient; private final CouponClient couponClient; private final RetryTemplate retryTemplate; public OrderCreatedEventHandler(InventoryClient inventoryClient, CouponClient couponClient) { this.inventoryClient = inventoryClient; this.couponClient = couponClient; // 配置重试策略：指数退避，最大重试3次 this.retryTemplate = RetryTemplate.builder() .maxAttempts(3) .exponentialBackoff(1000, 2, 10000) // 1s, 2s, 4s, 8s .retryOn(RemoteServiceException.class) .build(); } /** * 处理订单创建事件 * 注意：这里只做尝试性调用，失败进入补偿流程 */ @EventListener @Async("domainEventExecutor") public void handleOrderCreated(OrderCreatedEvent event) { OrderInfo order = event.getOrder(); // 异步扣减库存（最终一致性，允许短暂不一致） try { retryTemplate.execute(ctx -> { inventoryClient.deductStock(order.getSkuItems()); return null; }); } catch (RetryExhaustedException e) { log.error("库存扣减失败，进入补偿流程, orderId={}", order.getOrderId(), e); // 发送补偿消息，由人工或自动补偿流程处理 publishCompensationEvent(order, "INVENTORY_DEDUCT_FAILED"); } // 异步冻结优惠券 try { retryTemplate.execute(ctx -> { couponClient.freezeCoupon(order.getCouponId(), order.getOrderId()); return null; }); } catch (RetryExhaustedException e) { log.error("优惠券冻结失败，进入补偿流程, orderId={}", order.getOrderId(), e); publishCompensationEvent(order, "COUPON_FREEZE_FAILED"); } } }

六、实践反思

两年的中台建设带给我们的核心教训：

不要试图建设无所不包的"大一统"数据模型。我们曾花了三个月试图设计一个所有业务线通用的订单模型，结果每个业务线都有特殊要求，最终变成了一个字段超过200个的"超级表"，查询性能极差。后来改为"核心字段统一+扩展字段自治"的模式，问题才得以解决。
服务边界的划分要遵循"康威定律"。数据域的边界应该和团队的组织边界对齐。如果一个域需要两个团队协作才能完成一个需求，说明域的划分粒度可能需要调整。
最终一致性是不可回避的选择。在跨域的分布式环境中追求强一致性，只会让系统变得极其脆弱。接受最终一致性，做好补偿和幂等设计，才是务实的工程选择。

七、数据域拆分的量化决策模型

在实践中，判断一个数据域是否需要进一步拆分，可以参考以下量化指标：

团队修改冲突频率：如果同一个数据实体每周的并发修改PR超过5个，且经常需要跨团队协调，说明域的边界可能需要调整。
查询跨域JOIN比例：如果系统中超过30%的查询需要跨两个以上的数据域做JOIN（通过服务编排实现的"逻辑JOIN"），说明数据域的划分可能存在冗余，或者某些核心实体应该提升到更高的共享层级。
数据一致性事件日均量：基于事件的最终一致性方案会产生大量的补偿事件。如果日均补偿事件超过1000个，说明跨域的数据依赖过于紧密，应该考虑将强依赖的数据合并到同一个域中。

我们的经验是：数据域的划分不是一次性的架构设计，而是一个持续优化的过程。每季度应该对以上指标做一次复盘，根据业务演进调整域的边界。僵化地坚持初始设计，是中台项目失败的常见原因之一。

中台的架构设计没有标准答案，数据域划分需要在实践中不断调整。欢迎分享你的中台实践经验。

企业官网建设流程全解析