企业官网建设流程全解析

读完《微服务架构设计模式》第六章，我最大的感受是：事件溯源不属于那种你一眼看到就觉得很惊艳、但落地时无从下手的模式，它恰恰是那种需要你转变整个业务逻辑写法，才能体会到好处的东西。这一章标题是“使用事件溯源开发业务逻辑”，英文原文是 Developing Business Logic with Event Sourcing，核心讲的是一个老问题：微服务拆完之后，每个服务自己的业务规则和数据状态该怎么管？

我在自己负责的一个订单系统里，因为对账困难、状态机越写越乱，最终把核心域切成了事件溯源，这套笔记就是一边重翻这本书，一边把当时的实践重新梳理了一遍。如果你正被拆分后的数据一致性、聚合设计、复杂业务规则折磨，这一章的内容值得仔细读，本文也尽量把章里的思路和章外的坑一起讲清楚。

1. 为什么业务逻辑层会成为微服务的重灾区

1.1 微服务里最难的不是拆分接口，而是理清状态

微服务架构把大单体拆成了多个可以独立部署的服务，接口、网关、容器这些外围问题有大量成熟方案，真正让团队头疼的往往是业务逻辑层。单体时代，所有业务规则共享同一个数据库事务，订单状态可以随意更新，事务回滚保证数据最终一致；拆成微服务之后，每个服务有自己的数据库，一条业务链路要跨多个服务完成，状态分散在多个库、多张表里，修改一个状态可能级联影响多个服务。

这种情况下，业务逻辑的开发方式必须变。第六章一开始就点出了问题：服务内部的业务逻辑应该围绕聚合（Aggregate）来组织，而不是围绕数据库表来组织。聚合是一个设计模式概念，把一组高内聚的实体和值对象放在一个事务边界内，外部只能通过聚合根（Aggregate Root）操作内部状态。订单就是一个典型的聚合：订单项、收货地址、支付信息都是订单这个聚合的一部分，外部系统不能直接修改订单项，必须通过订单聚合暴露的方法来操作。

用聚合组织业务逻辑，最大的好处是让业务规则有了明确的归属。举个例子，一个订单只有处于已支付状态才能发货，这条规则写在订单聚合内部的 markAsShipped() 方法里，而不是散落在各个 Controller、Service、SQL 更新语句里。第六章强调，微服务里每个服务是独立部署的边界，聚合就是这个服务内部业务逻辑的边界。

但我当时实际做的时候发现，光有聚合还不够。聚合解决的是“规则放哪里”的问题，没有解决“状态怎么持久化”的问题。传统做法是把聚合当前状态直接序列化成数据库记录，这就是 CRUD 方式；事件溯源则提供了一条完全不同的持久化路径，这也是第六章用大量篇幅去讲事件溯源的原因。

1.2 事务脚本和领域模型为什么会有局限

第六章在讲事件溯源之前，先把业务逻辑的两种传统做法拉出来对比了一遍：事务脚本（Transaction Script）和领域模型（Domain Model）。

事务脚本是最常见的做法，一张表配一个 Service，业务逻辑写成一系列步骤。订单服务查询订单表，判断状态，执行更新，提交事务。这种做法的优点是直观、上手快，小型系统里效率很高；缺点是一旦业务规则复杂，比如订单要支持优惠、拆单、退款、售后，事务脚本会膨胀成一个大泥球，大量重复代码散落在不同方法里，改一个规则要动好几个地方。

领域模型比事务脚本更进一步，它把业务规则封装在聚合和实体对象里，通过状态和行为组织逻辑。第六章指出，领域模型的局限在于它依然依赖传统持久化机制——你把聚合当前状态存入数据库，下次读出来再重建聚合。这里有一系列隐含问题：为什么状态改变了？触发状态改变的业务事件没有保存；数据库里一条记录被覆盖，历史信息彻底丢失。

这两个问题在真实业务里非常致命。我记得团队处理过一个客诉：用户看到订单状态变成已发货，但仓库说根本没发过货。查数据库时，order_status 字段已经被更新为已发货，没人知道是谁在什么时间因为什么操作改成这个状态。如果采用事件溯源，每一次状态变化都会生成一个订单已发货事件，事件里带着操作人、时间、来源系统，这种问题几分钟就能定位。这也是第六章介绍事件溯源的出发点——把业务逻辑从面向状态的思维，切换成面向事件的思维。

1.3 事件溯源在整本书里的定位

《微服务架构设计模式》前面章节讲了服务的拆分、通信方式、Saga 分布式事务，事件溯源不是孤立出现的，它和 Saga、CQRS、领域事件这几个模式是配套使用的。第六章里的定位很清晰：事件溯源是一种开发单个服务内部业务逻辑的模式，它让服务内部的状态变化被记录成一系列不可变的事件，而 Saga 解决的是跨服务的长事务协调，CQRS 解决的是查询模型和命令模型的分离。

读这一章时要带着一个整体视角：事件溯源不是一个独立的银弹，它是微服务架构里的一个基础能力。你可以在订单服务里用事件溯源，同时让订单服务通过 Saga 和其他服务协作，让查询端通过 CQRS 构建专用的读模型。把这几个模式组合起来，才算真正发挥事件溯源的潜力。

2. 事件溯源在改什么：核心思路拆解

2.1 用事件流代替状态行

事件溯源的核心思想用一句话说就是：不保存当前状态，保存导致状态变化的每一个事件。传统的订单表存的是订单当前状态，比如待支付、已支付、已发货；事件溯源存储的是订单已创建、订单已支付、订单已发货这些事件。当前状态可以随时通过重放（replay）事件流得到，而不需要单独保存。

这个思路其实非常像记账。传统 CRUD 是拿橡皮擦改账本，错了就擦掉重写；事件溯源是往账本上不断追加记录，每一笔都带着时间戳、操作人，谁改的、改了什么、为什么改都清清楚楚。账本本身是不可变的，你只能不断追加新的记录。

用事件溯源开发业务逻辑，意味着聚合的行为会变成这样：外部调用方给聚合发命令，告诉聚合“你想做什么”，比如支付订单；聚合会先检查业务规则，比如订单是否处于待支付状态；规则检查通过后，聚合会产生一个事件，比如 OrderPaid；这个事件被追加到事件存储里；事件存储成功后，聚合的状态才会被更新。

这里有一个很重要的设计区别：命令（Command）是想做的事，事件（Event）是已经发生的事。命令是请求，可能被拒绝；事件是事实，不可撤销。第六章反复强调这个区别，因为很多人一开始会把命令和事件混在一起，导致设计出来的模型混乱。你在代码里会看到类似 payOrder() 这样的命令方法，方法内部校验各种规则后，会记录一个 orderPaid() 事件，而不是直接修改 paid=true 字段。

2.2 聚合的状态如何通过事件重建

事件溯源下，聚合的责任可以这样理解：它要消费命令，验证业务规则，产出事件；同时它也要消费事件，重建自己的内存状态。这两个过程对应两个核心方法。

第一个方法是处理命令的阶段。以订单聚合为例，方法签名大致是：

public class Order { private OrderState state; private List<OrderLineItem> lineItems; private List<DomainEvent> events = new ArrayList<>(); public void pay(PaymentInfo paymentInfo) { if (state != OrderState.PENDING_PAYMENT) { throw new IllegalStateException("订单不在待支付状态"); } if (lineItems.isEmpty()) { throw new IllegalStateException("订单没有商品"); } // 业务规则全通过，记录事件 addEvent(new OrderPaid(paymentInfo)); } private void addEvent(DomainEvent event) { events.add(event); } }

在这个阶段，聚合内部不会修改 state、lineItems 这些字段，它只负责校验规则，然后生成事件。

第二个方法是应用事件的阶段，用于从事件流重建聚合状态。事件溯源框架通常叫 apply 方法，或者用事件处理器的形式注册：

public class Order { public void apply(OrderPaid event) { this.state = OrderState.PAID; this.paymentInfo = event.getPaymentInfo(); } public void apply(OrderCreated event) { this.state = OrderState.PENDING_PAYMENT; this.lineItems = event.getLineItems(); } }

这里的关键在于，聚合是通过 apply 方法“听”事件来构建状态的，而不是通过数据库查询。事件存储里存了订单从创建开始的所有事件，需要用到订单时，把事件全部读出来，依次调用 apply，订单的当前状态就会在内存里重建出来。我第一次实现的时候，觉得这段逻辑特别绕，但写顺了之后，你会意识到这种做法的好处：订单状态的每一次变化都有据可查，聚合逻辑也天然集中于业务规则，不会散落到数据库更新代码里。

2.3 事件存储：数据库怎么选，表怎么设计

事件溯源绕不开事件存储。第六章没有规定一定要用哪种存储，只是强调事件是持久化的主要事实来源。我在实践中用过两类方案，效果都不错。

第一类是专门的事件存储数据库，比如 EventStoreDB，它本身就支持事件流、聚合快照、订阅等玩法，研发效率高。第二类是复用传统关系型数据库，加一张事件表。我们生产环境当时用的是 MySQL，事件表设计大致是：

CREATE TABLE order_events ( event_id BIGINT AUTO_INCREMENT PRIMARY KEY, aggregate_id VARCHAR(64) NOT NULL, event_type VARCHAR(128) NOT NULL, event_payload JSON NOT NULL, version INT NOT NULL, created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), UNIQUE KEY uk_aggregate_version (aggregate_id, version) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表里有几个字段特别关键。aggregate_id 是聚合的唯一标识，比如订单ID；version 是聚合内的版本号，每追加一个事件就加一，这个版本号是后面做乐观锁并发控制的核心；event_type 存事件类型，比如 OrderPaid、OrderShipped；event_payload 存具体业务数据，用 JSON 格式保存，方便反序列化。

需要注意的是，事件表和业务表如果放在同一个数据库实例，可以共用事务保证一致性。但微服务架构下，每个服务理应有自己的数据库，事件存储就在这个服务自己的库里面。跨服务的事件传播靠事件发布机制，第六章后面会结合消息代理讲这个点，我在第3节里也会专门展开。

2.4 为什么事件溯源能让业务逻辑更清晰

把当前状态改成事件流之后，业务逻辑的清晰度会有一个明显的提升。打个比方，传统 CRUD 像一个只告诉你“现在多少钱”的银行账户，事件溯源像一个能看完整交易明细的流水账。很多时候业务需要的恰恰是流水账，而不是一个简单的余额。

举一个电商里最常见的例子：用户取消订单。如果订单已经支付了，取消时要退款；如果订单已经发货了，就不能取消，只能走退货流程。这套规则如果用状态字段来实现，代码里会出现大量的 if-else 判断，而且随着状态增多，判断条件会越来越复杂。如果用事件溯源来实现，取消订单的命令处理逻辑就是检查当前聚合状态，已经支付就生成 OrderCancelled 和 RefundInitiated 两个事件，已经发货就抛异常提示走退货流程。

由于聚合状态来源于事件流，所以你能在代码里直接看到聚合经历过什么，业务规则也有了明确的依据。第六章把这个过程总结为“用事件来驱动业务规则”，这也是这一章最核心的思想：业务逻辑不只是操作数据，而是在生成事实、保存历史。

3. 用事件溯源开发业务逻辑的实操路线

3.1 从命令到事件的设计链路

落地事件溯源，最关键的一步是把业务操作建模成“命令-事件”的闭环。我在实操中总结了一个可复用的链路：接收命令 → 加载聚合 → 校验规则 → 生成事件 → 保存事件 → 发布事件。

第一步，接收命令。外部系统通过 Controller 或消息队列把命令发过来，比如 placeOrder、payOrder、shipOrder。命令是意图，不是事实，命令的命名用动词原形。

第二步，加载聚合。从事件存储里读出这个聚合的全部事件，通过 apply 方法重建聚合当前状态。为了性能，可以先读快照再读增量事件，快照的细节会在第4节讲。

第三步，校验规则。调聚合的命令方法，让聚合自己判断当前状态下命令是否合法。这一步会抛出各种领域异常，比如订单未支付不能发货。

第四步，生成事件。命令校验通过后，聚合返回一个或多个领域事件，这些事件还没有持久化，可以理解为内存中的事实。

第五步，保存事件。把所有生成的事件作为一条数据库事务写入事件表。这一步必须带上乐观锁版本检查，防止并发更新同一个聚合。

第六步，发布事件。事件保存成功之后，把它发布到消息代理，让其他服务可以订阅消费。这一步要注意事务和消息的一致性，不能事件存了但消息没发出去，或者消息发了事件没存。

这个链路看起来简单，但每一步都有很多细节。我当时踩过一个坑：第六步如果直接在事务里发消息，会存在事务提交前消息已发出的问题，消费者读到的业务数据可能还没提交。后来我们对 Kafka 场景用的方案是事务发件箱（Transactional Outbox），事件表里加一个 status 字段，另外起一个后台任务扫描未发布的事件发到 Kafka，发成功再更新状态。

3.2 命令验证和业务规则应该放在哪

事件溯源下，命令验证有两种级别：一种是命令本身格式的校验，比如参数不能为空、金额必须大于零，这种校验可以放在应用服务层；另一种是聚合状态的业务规则校验，比如订单是否处于可支付状态、是否重复支付，这种必须放在聚合内部。

第六章强调的是后者。业务规则属于聚合的私有逻辑，外部应用服务不应该替代聚合做业务判断。原因很简单：如果业务规则放在应用服务层，那么所有调用这个聚合的方法都得自己写一遍，业务规则没法复用到不同入口，代码迟早会失控。

具体落到代码，我习惯的做法是聚合内写一个 handle 方法，专门负责“命令→事件”的转换：

public class Order { public List<DomainEvent> handle(PayOrderCommand command) { validateStateForPayment(); validatePaymentAmount(command); return List.of(new OrderPaid(command.getPaymentInfo())); } }

这样的好处是，命令处理逻辑和应用事件逻辑分离。handle 负责规则校验，apply 负责状态变更，两者互不干扰。测试也更容易，只需要构造不同的聚合状态，调用 handle，检查返回的事件是否符合预期。

3.3 并发控制：事件版本号与乐观锁

事件溯源的多并发问题容易被人忽略，但一旦遇到就会非常头疼。想象一下两个请求同时支付同一个订单，两个请求都读取了 Events，都发现订单处于待支付状态，然后各自生成一个 OrderPaid 事件，都往数据库里追加。如果没有并发控制，订单最终会有两个支付事件，业务上不可接受。

第六章给出的解法是给聚合加版本号，每个聚合持久化时都带当前版本号，追加事件时带上版本号加一，数据库对 (aggregate_id, version) 建唯一索引，写成：

boolean updated = jdbcTemplate.update( "INSERT INTO order_events (aggregate_id, version, event_type, event_payload, created_at) " + "VALUES (?, ?, ?, ?, ?)", orderId, version + 1, eventType, payload, now ) > 0; if (!updated) { throw new OptimisticLockingException("并发冲突，版本号已更新"); }

数据库唯一索引会保证同一个聚合下，同一个版本号只能成功插入一次。第二个请求插入时因为版本号冲突失败，之后可以重试：重新读取最新事件流，重建聚合，再次校验规则。这就是乐观并发控制的标准套路。

实操中有个细节需要留意：如果一个命令会产生多个事件，比如取消已支付订单会同时产生 OrderCancelled 和 RefundRequested，那么这几个事件必须用同一个聚合版本号连续追加，并放进同一个本地事务里，保证要么全部成功，要么全部失败。这也是我说的事件表里 version 是聚合版本，不是事件自增号的原因——同一批产生的事件共享同一个 version 递增基准。

3.4 事件发布与订阅：打通事件溯源和微服务协作

事件溯源事件是写在一个服务自己的事件存储里，其他服务怎么知道你这边的状态发生了变化？答案就是事件发布和订阅。第六章结合整个微服务架构的上下文，强调事件溯源产出的领域事件，要通过消息代理广播给其他服务。

这里的核心问题是保证事件存储和事件发布的一致性。最简单可靠的做法是事务发件箱模式：事件表和发件箱表放在同一个本地事务里，事件写入后标记为“待发布”状态。后台有一个异步任务扫描发件箱中未发布的记录，把它们投递到消息代理，然后标记为“已发布”。

我当时用的是 RocketMQ，发件箱表和事件表结构上保持一致，投递逻辑大概这样：

public void publishPendingEvents() { List<OutboxMessage> pending = outboxRepository.findTop100ByStatus("PENDING"); for (OutboxMessage msg : pending) { SendResult result = rocketMQTemplate.syncSend("order-events", msg.getPayload()); if (result.getSendStatus() == SendStatus.SEND_OK) { outboxRepository.markPublished(msg.getId()); } } }

这套方案的优点是把事件存储和事件发布的强一致性问题，转成了“本地事务 + 最终投递”的弱一致性问题。事件只会被标记为待发布，不会因为消息代理故障而丢失；消费者那边要做幂等处理，因为发布过程可能重复投递。

订阅端也要注意消息顺序。Kafka 和 RocketMQ 按 key 分区是有序的，所以领域事件发布时，事件的 key 一定要用聚合 ID，比如订单ID，这样同一个订单的事件会发到同一个分区，消费者就能保证按顺序处理。如果随意用全局无 key 的消息，订单的已支付事件先于订单创建事件被消费，下游再去读订单时就会出问题。

4. 事件版本化、快照与重构：升级避坑实录

4.1 事件版本化的三种实操手法

事件一旦持久化，就不能修改，这个特性是事件溯源的基础。但业务是不断变化的，事件结构难免要调整。第六章专门讲了事件版本化的问题：你不可能要求线上已经存了几百万条事件，突然能适应新的字段结构，必须设计一套兼容旧事件的机制。

我遇到过的场景是，OrderShipped 事件原本只记录配送单号，后来业务要记录物流商编码，事件 payload 需要增加一个 carrierCode 字段。旧事件没有这个字段，直接反序列化会失败。

手工合一个项目中常用的三个方案。

第一种是宽松反序列化。事件对象里新加的字段允许为空，反序列化器碰到没有的字段直接填默认值。很多 JSON 框架默认就是这样做的，在新老事件共存时最容易落地。缺点是字段多了之后代码里到处要判空，事件语义会慢慢模糊。

第二种是升级器（Upcaster）。写一个专门的事件升级函数，把旧版本事件转换成新版本事件：

public class OrderShippedUpcaster implements EventUpcaster { @Override public EventData upcast(EventData oldEvent) { Map<String, Object> newPayload = oldEvent.getPayload(); newPayload.putIfAbsent("carrierCode", "UNKNOWN"); return new EventData(oldEvent.getType(), newPayload); } }

读取事件时，框架会先检查事件版本号，如果是旧版本，先走一遍升级器，把事件转换成最新格式，再进入 apply 方法。这个方案维护成本稍高，但能保持聚合内部代码始终面对最新结构，业务逻辑代码不会到处是兼容补丁。

第三种是策略模式适配器。为每个旧版本开发一个适配器，把旧事件的字段映射成新字段。说实话，除非事件结构发生大规模重构，否则不建议一上来就上这种方案，容易把事件溯源框架本身搞复杂。第六章里也给了类似建议，核心原则就是：事件是持久化的不可变事实，版本升级本质上是兼容层的堆叠，尽量不要破坏已有语义。

4.2 快照：控制聚合重建的开销

事件溯源一个绕不开的性能问题，是聚合重建需要加载全部事件。一个长期运行的订单聚合，如果包含几千个事件，每次读一次都要全量重放，数据库压力大、响应时间也长。第六章提到方案是做快照。

快照的思路很简单：每隔 N 个事件，把聚合的当前状态保存一份下来。重建时先加载最近一份快照，再重放快照之后的事件。比如订单每 100 个事件打一次快照，查询时加载到第 500 个事件的快照，再重放 501 到 520 的事件，就重建出最新状态。

快照在事件表里怎么存？两种常见设计：一种是单独一张 snapshot 表，字段包括 aggregate_id、version、state_payload、created_at；另一种是事件表里加一个 snapshot 标记。我比较推荐独立表，因为快照和事件的生命周期不完全一致，快照可以定期清理，不影响事件历史。

快照生成的时机要选好。我自己是把“每 N 个事件”和“每天一次”组合使用，一方面控制事件量，一方面避免某些活跃聚合高频重建。这里有个细节，快照本身不能替代事件，只是性能手段，事件永远是最完整、最可靠的事实来源。生成快照时如果并发写事件，要用和事件表一致的版本机制，防止快照和增量事件重复或漏掉。

4.3 事件的删除与合规问题

说到不可变事件，一定会有人提出合规要求：用户要求删除自己的数据怎么办？事件溯源的“不可变”特性，和真实业务里的数据删除需求有冲突。第六章实际上没有展开讲，但这是落地时躲不开的问题。

我在金融类项目里遇到过的做法是“加密事件 + 密钥销毁”：事件 payload 用加密存储，每个用户有独立的加密密钥，用户要求删除数据时，并不是物理删除事件，而是销毁用户的密钥，这样事件虽然还在，但已经不可读，从合规角度达成“删除”的目的。

另一种做法是事件中不存直接敏感数据。比如用户姓名不直接存事件里，而是存 user_id，查询时再通过受控接口获取；这样删除用户信息时只需要在用户服务里做逻辑删除，订单服务的事件里并不含敏感信息。这个设计越早做越好，等到事件都落库了再改，成本很高。

5. 常见问题与排查技巧实录

5.1 事件丢失或重复消费怎么排查

事件溯源系统上线后，最频繁的问题就是消息重复或者丢失。先说重复消费。只要引入了消息代理，消费者就必须做幂等处理。最稳妥的方式是在消费端建一张消费记录表，记录已经处理过的事件 ID：

CREATE TABLE processed_event ( consumer_id VARCHAR(64) NOT NULL, event_id BIGINT NOT NULL, created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), PRIMARY KEY (consumer_id, event_id) );

消费逻辑一开始先查记录，命中直接跳过；不命中就执行业务逻辑，然后在同一事务里写入记录。这里要特别注意，业务逻辑和记录插入必须放在同一个本地事务里，否则并发时还是可能重复处理。

丢失问题排查看两点：一是发件箱表里是否还有 PENDING 状态的老记录，二是后台扫描任务是否停止。还有一个容易被忽略的坑：发件箱任务投递成功后更新状态，但如果在投递时事务还没提交，消费者已经收到了消息，去查库会查不到业务数据。所以发件箱和消费者通常要配合幂等，消费端查到数据不存在时不直接报错，可以稍后重试。

5.2 聚合越变越大，重放越来越慢

事件溯源系统跑久了，活跃聚合的事件数量会越来越大，全量重放性能下降。除了快照，还有几个手段可以配合。第一是优化事件存储的读取，批量加载事件时一次查出来，而不是一条条查；第二是聚合设计层面减少事件总量，把低频变化的对象设计成独立聚合，不要让总聚合里包含过多子实体；第三是考虑用内存缓存，把高频聚合的重建结果缓存起来，靠失效机制保证一致性。

5.3 和 Saga 配合时的事务边界

事件溯源不能解决分布式事务问题，这一点一定要记住。订单服务内部用事件溯源，当订单状态变化后需要扣库存、扣余额时，跨服务的协调依然要交给 Saga。第六章在整本书的语境里，明确把事件溯源和 Saga 定位成互补关系。

我当时犯过的错误是，以为事件溯源之后就不需要 Saga 了，觉得事件流会自动传播状态。实际上，事件溯源只保证单个服务内状态变化的完整记录，跨服务的补偿、回滚、幂等还得靠 Saga 编排。正确做法是：事件溯源管服务内状态，Saga 管服务间协调，CQRS 管查询侧定制化读模型。

6. 读完这章后，我的实际应用与建议

6.1 哪些业务适合事件溯源，哪些别轻易上

第六章给了事件溯源的适用场景，但没给一个清晰的评估清单。根据我自己的经验，我会这么判断。

适合事件溯源的业务有这么几个特征：状态变化很重要，需要完整审计日志；业务规则复杂，状态机难以维护；需要对历史状态做追溯查询；一个聚合的写操作频繁，但并发冲突概率低。典型案例包括订单、金融账户、库存台账、积分流水。

不太适合的，是那些 CURD 为主、状态变化不关键、对性能极其敏感、团队对领域建模掌握很弱的场景。比如一个纯粹的内容列表、一个内部字典配置，就没有必要用事件溯源，普通 CRUD 更高效。

6.2 个人在落地中的几个关键经验

如果让我给准备用事件溯源的团队几句实在建议，第一句是不要一开始就全量改造，挑一个业务边界清晰、审计需求强的服务先试点。第二句是事件命名要语义完整，用过去时，OrderPaid 而不是 PayOrder，因为事件是已经发生的事实。第三句是一定要把事件表的老数据迁移、版本升级、发件箱监控这些运维工具在第一天就建好，否则系统上线一个月后你会被历史事件问题逼疯。

读完这一章，我对事件溯源的看法已经从“一个有趣的设计模式”变成了“一套完整的状态管理哲学”。它并不是银弹，但当你的核心业务需要完整的可追溯性、复杂的状态转移，以及跨服务可靠协作时，事件溯源给你的，远远比它拿走的多。如果你也在微服务里为业务逻辑头疼，这一章的阅读价值很高，建议带着自己的业务案例，边想边读。