SaaS Architecture & Startup Engineering · 课时

微服务事件风暴

利用事件风暴这一协作技术发现领域事件，并为 SaaS 建模复杂的业务流程

微服务事件风暴 是 CoddyKit 上的免费 SaaS Architecture & Startup Engineering 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 SaaS Architecture & Startup Engineering 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 SaaS Architecture & Startup Engineering 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

What is Event Storming?

Event Storming is a fun, collaborative workshop technique to understand complex business domains. It helps teams visualize how things happen in a system.

Imagine a room full of sticky notes! Teams map out a business process by focusing on the "events" that occur, making it easier to see the big picture.

Why Event Storm for Microservices?

For SaaS, especially with microservices, understanding domain boundaries is key. Event Storming helps:

Break down monoliths: Clearly identifies areas to split.
Define service boundaries: Groups related events and actions into potential services.
Improve communication: Gets everyone on the same page, from business to tech.

The Event Storming Canvas

Event Storming uses different colored sticky notes to represent various elements of your domain:

Orange: Domain Events (what happened?)
Blue: Commands (what triggers an event?)
Yellow: Aggregates (who performs a command?)
Green: Read Models (how users view data?)
Purple: Policies (rules reacting to events)

Step 1: Discovering Domain Events

This is the starting point! Think about "what happened?" in your business process. Events are facts from the past, always written in past tense.

Examples:

OrderPlaced
PaymentReceived
UserRegistered
SubscriptionCancelled

These are the core truths of your system.

Coding a Simple Event

While Event Storming is visual, the events we discover often translate into code. Here's how a simple OrderPlaced event might look in a Java application:

Try running this example to see how an event could be represented and "published" (here, just printed).

public class OrderPlacedEvent {
  private String orderId;
  private double amount;
  private String customerId;

  public OrderPlacedEvent(String orderId, double amount, String customerId) {
    this.orderId = orderId;
    this.amount = amount;
    this.customerId = customerId;
  }

  public String toString() {
    return "OrderPlacedEvent {id='" + orderId + "', amount=" + amount + ", customerId='" + customerId + "'}";
  }

  public static void main(String[] args) {
    OrderPlacedEvent event = new OrderPlacedEvent("ORD123", 99.99, "CUST456");
    System.out.println("New event generated: " + event.toString());
  }
}

Step 2: Identifying Commands

After events, we look for commands. A command is an explicit request to do something, which usually leads to an event (or multiple events).

Ask: "What action caused this event to happen?" Commands are usually imperative verbs.

PlaceOrder (leads to OrderPlaced)
ProcessPayment (leads to PaymentReceived)
RegisterUser (leads to UserRegistered)

Step 3: Pinpointing Aggregates

Aggregates are the "who" or "what" that receives a command and produces an event. They are transactional consistency boundaries – meaning everything within an aggregate changes together.

Think of them as the "model" or "entity" in your code that holds state and enforces business rules.

Order aggregate handles PlaceOrder.
PaymentProcessor handles ProcessPayment.

Step 4: Read Models & Policies

Read Models (Green): These are how users or other systems query information. They are optimized for reading, often denormalized views built from events.

Policies (Purple): These are business rules that react to events. For example, "when an OrderPlaced event occurs, then send a confirmation email."

From Storm to Bounded Contexts

As you map out your domain, you'll see natural clusters of events, commands, and aggregates. These clusters often define your Bounded Contexts.

A Bounded Context is a logical boundary within which a specific domain model is defined and applicable. This is crucial for designing independent microservices!

Benefits Beyond Design

Event Storming doesn't just help with technical design; it fosters a shared understanding across the entire team.

Shared Language: Everyone uses the same terms.
Knowledge Transfer: New team members quickly grasp complex flows.
Problem Identification: Uncovers hidden assumptions and issues early.

Quick Check

Event Storming uses different colored sticky notes to represent various domain elements. Match the sticky note color to its correct description.

Recap: Event Storming Toolkit

You've learned that Event Storming is a powerful, visual technique to understand complex domains. By focusing on Domain Events, you can identify Commands, Aggregates, Read Models, and Policies.

This collaborative approach helps in defining clear Bounded Contexts, making it an invaluable tool for designing robust and scalable microservices in your SaaS architecture.

常见问题解答

「微服务事件风暴」课时是免费的吗？

是的 — 「微服务事件风暴」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 SaaS Architecture & Startup Engineering 课程的其余内容，请升级到 CoddyKit PRO。 SaaS Architecture & Startup Engineering 课程共包含 4 节课。

「微服务事件风暴」这节课中我会学到什么？

利用事件风暴这一协作技术发现领域事件，并为 SaaS 建模复杂的业务流程你通过在浏览器中直接运行的动手代码来练习 SaaS Architecture & Startup Engineering，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 SaaS Architecture & Startup Engineering 需要有经验吗？

无需任何先前经验。CoddyKit 上的 SaaS Architecture & Startup Engineering 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「微服务事件风暴」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 SaaS Architecture & Startup Engineering 课中编写并运行代码吗？

能。每节 SaaS Architecture & Startup Engineering 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 SaaS Architecture & Startup Engineering