Od wielu lat rozmawiamy o tworzeniu systemów, które są lepiej podzielone. Łatwiejsze w rozbudowie i utrzymaniu, pięknie napisane i dobrze podzielone na moduły. Wiele czasu poświęciliśmy na dyskusje o mikroserwisach, CQRS, event sourcingu, itp. Ale czy można prościej? Postaram się przybliżyć proste podejście do event-driven architecture, wspomnę też o wadach.

1. www.accesto.com
Event Driven
Architecture, the easy way
Michał Kurzeja, Accesto

3. “the easy way”?

4. Co to jest Event
Driven Architecture*?
*Architektura sterowana zdarzeniowo

5. Co to jest zdarzenie?

9. Czym nie jest Event Driven Architecture?
- EDA to nie mirkoserwisy
- EDA nie musi być asynchroniczne

10. Podejście Tradycyjne czyli “nie Event-Driven”

12. !!!

14. Różne znaczenia
“event-driven”

15. 1. Event notification

16. Event Notification

18. 2. Event carried state

19. Event-carried state

20. Event-carried state

21. 3. Event Sourcing

22. Event Sourcing

23. Event Sourcing

24. Event Sourcing
● Audyt
● Debugowanie
● Historyczny stan
● Alternatywny stan
● W praktyce - duużo trudniejsze niż się wydaje

25. 4. CQRS

26. CQRS

27. CQRS

28. Prosta implementacja

32. Zalety tego podejścia Event Driven
- Łatwe skalowanie
- Łatwe rozszerzanie
- niski coupling (niskie sprzęganie)
- niskie koszty
- łatwe wdrożenie w istniejących systemach

33. Czy coś tracimy
- audyt?
- historyczny i alternatywny stan
- wydajność?

34. Częste błędy

35. Zła nazwa
- brak czasu przeszłego
- AssignTask
- przekazanie intencji
- SendNotification
- powoduje brak rozszerzalności kodu
- nazwa handlera

37. Generalizowanie
- skup się na zachowaniu
- a nie na danych
- Prawidłowo:
- OrderConfirmed
- OrderShipped
- Nieprawidłowo:
- OrderChanged, OrderUpdated

38. “Prosty” async
- “tylko zmienimy transport”
- Problemy
- duuużo, ale o tym zaraz

39. Popularne problemy

40. “Prosty” async
- niespodzianki w “legacy”
- retry
- systemy zewnętrzne
- dostarczenie (jedno, brak, wielokrotne)

41. “Prosty” async - zgubione zdarzenie
- gubimy np. start transakcji, albo utworzenie czegoś
- co jeśli przyjdzie event zakończenia, albo zmiany tego
“Czegoś”

43. Przepływ zdarzeń a transakcje

44. Przepływ zdarzeń a transakcje

45. Przepływ zdarzeń a transakcje
doctrine_transaction middleware

46. Przepływ zdarzeń i transakcje
● Zdarzenie wysłane, a transakcja odrzucona
● Transakcja przeszła, ale nie udało się wysłać zdarzenia

47. Przepływ zdarzeń a transakcje
commit do db jest tu
DispatchAfterCurrentBusStamp, DispatchAfterCurrentBusMiddleware

48. Async a przepływ zdarzeń a transakcje
- At most once delivery - możliwe przeoczenie
- At least once delivery - możliwa duplikacja
- at most once processing
- “Listen to yourself”

50. Obsługa błędów
- Jak wpływa na przepływ zdarzeń w systemie?
- Czy błąd jest “blokujący”
- Czy warto błąd obsługiwać?

51. Ukryte intencje
- Co jeśli OCZEKUJEMY reakcji na event?
- Co jeśli OCZEKUJEMY informacji zwrotnej?
Wzorzec SAGA, Process Manager

52. Zdarzenia a czas
- kiedy zdarzenie zaszło?
- problem z danymi w zdarzeniu, czy są aktualne
- dotyczy “grubych” zdarzeń

53. Event cascades, nieznane flow

54. Causation/Correlation ID

55. Pominięcie
Wszystko musi iść przez system,
np. bezpośrednia zmiana w db nie jest możliwa

56. EDA? Bardzo chętnie!

57. “Gratisowe” zalety
- bardzo prosta integracja z innymi systemami
- uproszczone debugowanie
- korzystamy z causation/correlation id i Datadog
- i więcej

58. Decoupling na siłę to
zły pomysł

59. Pytania?

60. Pytania po prezentacji? Napisz do mnie! :)
michal@accesto.com
accesto.com/blog/
Kontakt
twitter.com/accestoPL
facebook.com/accesto