This document discusses common traps that can be encountered when implementing an event-driven architecture and provides solutions to avoid them. It covers traps such as missing domain events, versioning of behaviors and data over time, issues with external calls and consistency, ignoring the CAP theorem, having anemic domain events, and versioning of event schemas. The document provides explanations for why each trap occurs and recommends approaches like event storming, embedding results in domain events, weak schemas, and schema translation to help address the issues.
2. JakubPilimon
DISCLAIMERS
• Traps based on private experiences
• Solutions worked in my contexts
• Haven’t pushed anything to production since … 6 months
• … But this is based on previous experiences
• Completely new content, so things might not work
• … Please don’t throw tomatoes
3. JakubPilimon
WHOAMI
SPRING DEVELOPER ADVOCATE
AND PROGRAMMER
Loves to tackle complex enterprises with:
• Domain-Driven Design,
• Event Storming,
• Test-Driven Development,
• Spring
Being a microservice freak, architecture is his main area of interest too.
DZone MVB awarded blog: pillopl.github.io
Co-founder of #dddbyexamples initiative: github.com/ddd-by-examples
5. JakubPilimon
EVENT-DRIVEN TO ME
• EDA != “I have microservices”
• EDA != “I have a message broker”
• Events might be transported for instance via HTTP
• Events can live only in application memory
• … Events might not be even visible in the code
• … but domain event is there in the business process
• Event Sourcing counts too
10. JakubPilimon
TRAP #1: MISSING AN EVENT
REASONS:
▸ Treating boundary of software as equals to boundary of business process
▸ Not spotting that our piece of software is not source of truth
▸ There is semantics of the protocol and there is implementation
SOLUTIONS:
▸ Event Storming can help you find EXTERNAL events and boundaries of your software
▸ Think about assumptions you make about consistency and don’t try to be consistent
no matter what (sometimes it is impossible)
▸ Attach to semantics, not to implementation (focus on an intention of any
communication)
13. JakubPilimon
TRAP #2: VERSIONING OF BEHAVIORS
REASONS:
▸ Hard-coded values are not temporal
▸ Occurred vs Arrived mismatch!
SOLUTIONS:
▸ Calculation logic in projection should be done at time of event creation
and the result should be inside the event
▸ Same with external calls
16. JakubPilimon
TRAP #3: EXTERNAL CALLS
REASONS:
▸ Thinking that external systems are always temporal
▸ Relying on single point of truth
SOLUTIONS:
▸ External calls should be done at time of event creation and the result should be
inside the event
▸ Listening to another upstream of events and join both streams by building local
read model
20. JakubPilimon
TRAP #5: ANEMIC-EVENTS
REASONS:
▸ Focusing on data instead of behaviors
SOLUTIONS:
▸ Domain events (with behavior)
▸ Thinking about business intent of any change, not only
about the representation of that change
22. JakubPilimon
TRAP #4: IGNORING CAP THEOREM
REASONS:
▸ Ignoring the fact that every now and then things will not work
▸ Trying to be consistent NOW!
▸ Experience with 2PC
SOLUTIONS:
▸ At-least once (and deduplicating) or at-most once
▸ Event sourcing
▸ Listen to yourself
▸ Log tailing