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
tomokusaba
fd0
kuralab
nnaka2992
fufufukakaka
taishiyade
elmetal
nealle
kasacchiful
taiseiue
k1tikurisu
devoc
bermonpainter
michaelherold
nonsquared
cassininazir
eitanlees
shpigford
moore
jlugia
rasmusluckow
smashingmag
keithpitt
chrislema
