Defining Event Modeled systems with AsyncAPI
summary
Event Modeling produces a single information blueprint (seven workshop steps, typically 3–5 days) that maps commands, events and read views to AsyncAPI channels; a concrete hotel-management WebSocket project shows commands published, events subscribed, headers carrying causation ID and command ID, and views as subscribe-only data. Tooling generates command handlers and WebSocket routes from the spec. Notes: about 90–95% payload match between command and resulting event, no built‑in call/response for failures, and catch‑up must be implemented.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 0:45Event Modeling
- 1:25Workshop
- 3:18Steps
- 3:49Brainstorm
- 5:07Plot
- 5:53Storyboard
- 8:12Views
- 9:18Conways Law
- 11:03Status scenarios
- 13:01Event commands views
- 13:19Async API
- 16:20Async API Views
- 17:38Async API Code
- 20:33View Code
- 22:23Shared Headers
- 24:18Generated Sources
related talks
34mAsyncAPI and DDD - A Pretty Couple
46mEvent Modeling from Beginner to Expert
56mEvents on the outside, on the inside and at the core
31mHow EventStorming Transformed Our Domain Modeling Process
01h 12mDemystifying "event-based" software concepts and methodologies
44mThe Dark Side of Events
47mComplexity is the Gotcha of Event-driven Architecture
50mHow EventStorming Transformed Our Domain Modeling Process