1. 事件溯源（Event Sourcing）场景下事件命名如何同时满足业务可读性与版本向前兼容要求；列举常见的"动词过去时"与"业务结果型"两种命名风格的取舍
在事件溯源架构中，领域事件是唯一的事实来源（single source of truth），其命名既要让业务人员能读懂历史发生了什么，又要保证事件在消费者升级后仍能正确反序列化。请说明如何命名事件，并比较"动词过去时"（如 OrderPlaced）与"业务结果型"（如 OrderConfirmed）两种风格？
- 事件命名需要同时满足"业务可读性"（业务人员能看懂）与"版本兼容"（老事件可被新代码消费）
- 事件是不可变的已发生事实，命名应体现"已经发生"的语义
- 结构与语义的兼容性如何通过命名与 schema 演进共同保障
（1）命名原则：事件名是一个完整的名词短语，表示"已经发生的事实"，通常用动词过去时或过去分词。核心是"做出来了"而非"要做"，因此命名要避免命令式（如 PlaceOrder）与未来时（如 WillPlaceOrder），因为那是命令而非事件。事件名是聚合名 + 强动词过去式，例如 OrderPlaced、MoneyDeposited、OrderCancelled。 （2）"动词过去时"风格（Process-style）：OrderPlaced、PaymentReceived、ItemShipped。它描述"系统做了什么动作"，层次贴近实现过程，容易让多个事件表达同一业务结果的不同阶段（如 Placed→Paid→Shipped）。优点是事件粒度细、可追溯性强；缺点是业务结果不直观，且一旦流程重排，事件名可能与业务语义脱节。 （3）"业务结果型"风格（Result-style）：OrderConfirmed、PaymentSettled。它描述"业务最终达成了什么结果"，读起来更像业务语言，便于业务人员理解。缺点是可能掩盖过程中的中间状态（若业务需要区分"已受理"与"已确认"就难以表达）。 （4）取舍建议：以业务结果为导向命名主事件，以过程事件作为补充；当过程中间状态对业务有真实意义时，用动词过去时保留。关键是全团队通过统一语言（Ubiquitous Language）约定事件词典，避免两种风格混用浪费认知。 （5）版本向前兼容的配套手段：事件名本身不变，但增加 schemaVersion / eventType 字段；通过 Avro schema registry、Protobuf 的 reserved 字段、或 JSON Schema 的 version 字段做向前兼容。消费者只依赖事件名 + 版本字段，先按版本选择反序列化器，再落到业务逻辑。这样即使事件结构演进，旧事件仍可被新消费者正确读取。
事件命名是事件溯源最容易被低估的决策，因为它一旦写入 event store 就不可更改。命名既要服务人（业务可读），又要服务机器（可反序列化），因此实践中"动词过去时 + 业务结果型"两种风格并存，团队应通过事件词典与 schema 版本机制来统一并保证兼容。
// 事件名 + 版本字段，保证向前兼容
public class OrderPlaced implements DomainEvent {
private final int schemaVersion = 1; // 结构演进时递增
private final String orderId;
private final Money totalAmount;
// getters...
}
// 反序列化时先按版本选择 schema
public DomainEvent deserialize(String eventType, int version, byte[] payload) {
if (eventType.equals("OrderPlaced") && version == 1) {
return mapper.readValue(payload, OrderPlacedV1.class);
}
throw new UnknownEventException(eventType, version);
}