Response Communication Pattern Query A request for information about the current state of one or many objects The requested information Request-Response Command An intention to perform an operation or change a state A confirmation that the command has been executed, or an error message if the command failed Request-Response Event A fact, something that undisputedly happened in the past None (events are facts, they can’t “fail”) Fire-and-Forget
via streams of events. - Between services (macroarchitecture) Event Sourcing - Instead of storing the current state, a sequence of events leading to that state is stored. - Within a service (microarchitecture) 9
services, to improve scalability and resilience of the system. Event Sourcing - Capturing changes within a service as a sequence of immutable, time-ordered events, to make the entire history transparent and replayable. 12
Sourcing Is 3. The Why of EDA and Event Sourcing 4. Loose coupling is great. And a very broad term. 5. Events are both triggers and data Next: Implementation
be able to restore the current state of your aggregate quickly, to enforce invariants. Use a Database, thank me later. See e.g. https://www.linkedin.com/posts/vaughnvernon_event-sourcing-and-mes sage-streaming-are-activity-7153936417142788097-gxTv 36
event to be a “poison pillˮ. Can be ok. If not: Build your own (stash event, remember key as “blockedˮ, continue with others). Iirc Google Pub/Sub offers a bit more convenience. 39
fit for EDA 7. The transactional outbox is essential 8 ."Transactional Inbox" is an anti-pattern 9. Kafka is not good for event sourcing 10. Kafka consumer error handling is too basic 11. Itʼs not more more less complexity, it just moves elsewhere Next: Diving Deeper
the temporal decoupling - Break the event / state correlation - Recommendation: Only use to refer to immutable objects - Good use: Big, immutable data such as generated PDFs - Or: For big group of subscribers that are supposed to see different parts of the information?
More About Commands Vs. Events 14. EDA is not only about events 15. It's important to keep your promises 16. Separate Observing From Control 17. Bring the Data to the Process 18. Don't fight complexity with complexity 19. Embrace constraints, donʼt fight them Next: The Principles are Everywhere
do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. ... 81 $ Cat file3.txt | grep “oop” | tee file4.txt | wc –l
[..] provides a repository of tuples that can be accessed concurrently. As an illustrative example, consider that there are a group of processors that produce pieces of data and a group of processors that use the data. Producers post their data as tuples in the space, and the consumers then retrieve data from the space that match a certain pattern.
the picture on the previous slide is from) https://en.wikipedia.org/wiki/Tuple_space (that’s where the text on the slide before that is from) https://en.wikipedia.org/wiki/Jini
fit for EDA 7. The transactional outbox is essential 8 ."Transactional Inbox" is an anti-pattern 9. Kafka is not good for event sourcing 10. Kafka consumer error handling is too basic 11. Itʼs not more more less complexity, it just moves elsewhere
More About Commands Vs. Events 14. EDA is not only about events 15. It's important to keep your promises 16. Separate Observing From Control 17. Bring the Data to the Process 18. Don't fight complexity with complexity 19. Embrace constraints, donʼt fight them
lutzh
maroon1st
yuki0329
oniak3ibm
.png){kind=avatar}
oidy
tokujiros
eddie
lamodatech
oguemon
k1tikurisu
aki19035vc
ymd65536
tomokusaba
bryan
mclloyd
marktimemedia
yeseniaperezcruz
thekraken
soudai
shlominoach
addyosmani
tammyeverts
tenderlove
csswizardry
orderedlist
