⏱️Why Event-Based systems Rock 🤘 [in 5 tweets].
Designing systems from domain events instead of columns in a database, endpoints on an API, or components in a view, has so many benefits.
#ddd #eventstorming
Designing systems from domain events instead of columns in a database, endpoints on an API, or components in a view, has so many benefits.
#ddd #eventstorming
[Communcation] Thinking in terms of domain events is the closest we can get to expressing what happens in the real world. Features can be communicated by non-technical folk as a series of domain events.
UserRegistered -> EmailVerificationSent -> EmailVerified
UserRegistered -> EmailVerificationSent -> EmailVerified
[Auditing & Reasoning] When we represent a system using events, we can reason about the way that the system changed over time since the current state is computed by applying all of the domain events that ever occurred. In some domains, this is mandatory for audits.
[Estimates] Software can be a very creatively unbounded process. Find and count all the `views` (read models) that present data and `commands` (write models) that change the system and cause domain events, then measure their complexity.
[Scalability] Sometimes, in large applications- a single transaction might need to pass through or notify several other systems. In high-traffic scenarios, instead of blocking an async call, we introduce "Eventual Consistency" as a way to enable systems to "catch up" eventually.
[Complexity] Business rules are often missed in CRUD-first design. In order to avoid unmaintainable `if` and `else` statements, think in terms of events, the commands they sometimes invoke as side effects, and the preconditions that govern how and when they can be invoked.
