<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>outbox-pattern on </title>
    <link>/tags/outbox-pattern/</link>
    <description>Recent content in outbox-pattern on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sat, 04 Apr 2026 10:00:00 +0800</lastBuildDate><atom:link href="/tags/outbox-pattern/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Spring Boot 3.5 &#43; Java 25 &#43; Cloud Native 系列（五）：事件驱动架构</title>
      <link>/posts/shop-platform-event-driven/</link>
      <pubDate>Sat, 04 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/shop-platform-event-driven/</guid>
      <description>在之前的文章中，我们看了同步请求链路上的 Gateway → BFF → 领域服务。但微服务架构中并不是所有交互都适合同步发生。事件驱动架构让服务之间通过异步消息协作，在不少场景下用最终一致性换取更低耦合和更好的链路弹性。
📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
上一篇：（四）领域服务设计
2026-04 实践更新 当前主线仓库已经把 IdempotencyGuard + Redis Bloom Filter、补偿任务重试、以及关键 Kafka consumer 的幂等保护补齐到 Phase 1 基线；本文整体设计仍然准确，但“待补齐”的幂等链路请以当前 main 分支实现为准。
为什么用事件驱动 在 Shop Platform 中，异步事件主要用来承接那些不必阻塞用户请求、但又需要可靠传播的业务事实。例如：
flowchart TD Order[&#34;用户下单order-service&#34;] Stock[&#34;扣库存marketplace-service&#34;] Points[&#34;发积分loyalty-service&#34;] Email[&#34;发邮件通知notification-service&#34;] Webhook[&#34;推送外部订阅webhook-service&#34;] Order --&gt;|&#34;同步 需要立即确认&#34;| Stock Order -.-&gt;|&#34;异步 可以延迟&#34;| Points Order -.-&gt;|&#34;异步&#34;| Email Order -.-&gt;|&#34;异步&#34;| Webhook 如果全部走同步 HTTP 调用：
下单接口响应时间 = 最慢下游服务的响应时间 任意下游服务不可用 → 下单失败 服务间耦合紧，新增消费者需要修改生产者 事件驱动的方式：
flowchart LR OS[&#34;order-service写入订单 + outbox同一事务&#34;] Pub[&#34;Outbox Publisher&#34;] Kafka[&#34;Kafkaorder.events.v1&#34;] L[&#34;</description>
    </item>
    
    <item>
      <title>Spring Boot 3.5 &#43; Java 25 &#43; Cloud Native 系列（四）：领域服务设计</title>
      <link>/posts/shop-platform-domain-services/</link>
      <pubDate>Fri, 03 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/shop-platform-domain-services/</guid>
      <description>在前两篇文章中，我们看了 API Gateway 的路由分发和 BFF 的聚合编排。这一篇继续往里走，看看业务承载最集中的一层——领域服务层。
📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
上一篇：（三）BFF 聚合层
2026-04 实践更新 领域服务侧当前已经和早期文章发布时相比前进了一步：Problem Details、@ServiceConnection、补偿任务持久化、Kafka 幂等守卫都已落地；本文中的领域边界划分仍然成立，但涉及“后续会做”的部分请以主线仓库现状为准。
领域服务清单 Shop Platform 核心业务按边界拆成 11 个领域服务，每个服务独立开发、独立部署、拥有自己的数据库 schema；此外 auth-server 自己维护 shop_auth，但它更偏认证边界，本文重点放在业务域服务。
服务 数据库 核心业务 profile-service shop_profile 用户档案、地址簿、卖家档案 marketplace-service shop_marketplace 商品目录、SKU、库存、评价 order-service shop_order 订单状态机、购物车、退款 wallet-service shop_wallet 钱包余额、充值、Stripe 支付 promotion-service shop_promotion 促销引擎、优惠券 loyalty-service shop_loyalty 积分账户、签到、兑换 activity-service shop_activity 插件化游戏引擎 search-service — Meilisearch 集成、Feature Toggle notification-service shop_notification 邮件通知、Channel SPI webhook-service shop_webhook 开放平台 Webhook、HMAC 签名 subscription-service shop_subscription 订阅计划、自动续费 其中 search-service 没有关系型数据库——它的数据存储在 Meilisearch 搜索引擎中。</description>
    </item>
    
  </channel>
</rss>
