一个多租户、多品类的创意变现平台，在产品上复杂，在架构上也并不轻松。回顾 CHY3 从零到一的过程，有三个决定值得分享：服务边界、数据管道和支付集成。
按业务域划分边界
最需要慎重的决定，是服务切在哪里。我们的规则是按业务域切，而不是按技术层切。创意管理、支付结算、分析报表和用户身份是四个有界上下文，各自拥有存储和领域模型。这样可以在早期避免分布式事务，同时让每个上下文独立演进。服务间通信以异步消息队列为主，只在关键路径上使用同步 gRPC。
事件管道
创意变现产生的数据极其异质：支付回调、产品埋点、内容消费日志，以及第三方 API。我们围绕变更数据捕获和 Kafka 构建了一条流式管道，把每个业务事件归一化为 CloudEvents 信封。下游系统——分析、告警、推荐——订阅事件类型，而不是查询上游数据库。
支付作为防腐层
支付是离钱最近、也最不允许出错的部分。我们的设计把每个支付渠道当作外部的防腐层。平台内部只暴露统一的「价值转移」抽象；订阅管理、收入计算和结算逻辑永远不会看到渠道特有的细节。幂等键和补偿事务保护账本，即使回调重试或渠道超时。同一条边界，也为未来的区域合规和税务计算留出了空间。
经验
架构是一组被刻意选择的约束。目标不是为所有未来做好准备，而是让下一次变化足够便宜。