Navigating complexity in event-driven architectures: A domain-driven approach
summary
Event systems start simple but an implementation‑first approach reliably produces a “distributed big ball of mud”: undocumented payloads, leaking PII, no versioning and exploding coupling. Domain‑driven techniques like event storming and bounded contexts plus patterns such as anti‑corruption layer or open‑host‑service reduce that accidental complexity. Recommended specs and tools: CloudEvents, AsyncAPI, OpenAPI, Azo and the X‑registry; an open‑source Event Catalog is built and in use (≈28,000 catalogs created) to improve discoverability.
AI-written summary · about
chapters (13)
- 0:00Event-driven architectures intro
- 1:09Complexity in event-driven systems
- 8:43Architecture growth warning signs
- 11:13From simple to chaotic events
- 19:42DDD for complexity management
- 23:55Event storming for domains
- 30:16Bounded contexts in DDD
- 33:01Event consumption coupling risks
- 39:29Producers unaware of consumers
- 41:17Standards for governance
- 45:08DDD with event cataloging
- 48:42Summary and key takeaways
- 50:50Q&A
related talks
55mNavigating complexity in event-driven architectures: A domain-driven approach
44mComplexity is the Gotcha of Event-driven Architecture
54mSo You Want to Build An Event Driven System?
47mAccelerating Event-driven Architecture with Domain-driven Design
42mDesign Principles for an Event-Driven Architecture
52mSo You Want to Build An Event Driven System?
46mManaging Event Driven Architectures
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets