Navigating complexity in event-driven architectures: A domain-driven approach
summary
Event-driven systems start simple and then suffer accidental complexity: undocumented payloads, leaked implementation details, unknown consumers and a “distributed big ball of mud.” The pragmatic fix is behavior-first: use event storming to create ubiquitous language and bounded contexts, apply anti‑corruption layers or partnership/conformist mappings between domains, and adopt specs like CloudEvents and AsyncAPI. A concrete outcome is the open‑source Event Catalog (MIT) that documents schemas, visualizes flows and bounded contexts — ~20,000 catalogs exist and ~1,000 people join its Discord.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:32The complexity challenge
- 3:38Adoption and promise
- 6:41Warning signs of complexity
- 9:37The big ball of mud
- 12:13Event design problems
- 15:19Event notification issues
- 18:01Event state transfer risks
- 20:47Domain driven design
- 25:51Domain discovery techniques
- 29:47Event storming in action
- 32:37Bounded context importance
- 35:10Bounded context mappings
- 39:27Coupling and distance
- 41:45Governance requirements
- 43:56Open source standards
- 47:19EventCatalog tool
- 51:05Summary and resources
related talks
52mNavigating complexity in event-driven architectures: A domain-driven approach
44mComplexity is the Gotcha of Event-driven Architecture
47mAccelerating Event-driven Architecture with Domain-driven Design
54mSo You Want to Build An Event Driven System?
42mDesign Principles for an Event-Driven Architecture
46mManaging Event Driven Architectures
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
31mDemystifying Event-Driven Architectures