Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

AXON FRAMEWORK

No description
by

Kamil Essekkat

on 7 May 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of AXON FRAMEWORK

DDD
CQRS/ES
Axon
Axon ~SWOT

AXON FRAMEWORK
Domain driven design
DOMAIN
pol. domena, dziedzina
opis zagadnienia bez szczegółów technicznych

powinna być zrozumiała dla wszystkich interesariuszy
By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.
[…]
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

-- Eric Evans
DESIGN
Jakimi pryncypiami kierujemy się tworząc software?
Source:
http://michalorman.com/img/rails-hexagonal-architecture.png
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be
developed and tested in isolation
from its eventual run-time devices and databases.

-- Alistair Cockburn
Source:
https://blog.rescale.com/openclosed-and-the-single-responsibility-principle/
CQRS
Command Query Responsibility Segregation
ES
Event Sourcing
CQRS - zapis i odczyt powinny być rozdzielne. Zaczynając od poziomu API, kończąc na bazach danych.
Np.:
zapis danych (command) jest kierowany
do Postgres, a odczyty z Redisa.
Albo:
zapisujemy na masterze (Postgres), a czytamy ze slave'a
Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one.
The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation,
a command is any method that mutates state and a query is any method that returns a value).


-- Greg Young
Event Sourcing - rozbicie stanu obiektu na ciąg zdarzeń

Myśl:
git i commity
Oracle i redo log
Event Sourcing ensures that all changes to application state are stored as a sequence of events.
Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.

-- Martin Fowler
Dzięki ES osiągamy pełną audytowalność stanu.

Axon dodatkowo wprowadza możliwość rozproszenia przetwarzania eventów.
Jedną z opcji jest ich wysyłanie na EAI.
Glosariusz
Event

Wydarzenie, zmiana stanu. Zwykle czas przeszły, dokonany.
Przykłady:
CustomerRegistered
AccountBlocked
OrderDeleted
Aggregate Root

Zbiór stanów; istniejący w aplikacji.
Przykłady:
klient Jan Kowalski
pakiet MIX.

Stan agregatu wynika
wyłącznie
z odebranych eventów!
Event Stream

Seria zdarzeń dotycząca jednego agregatu.



Event Store

Baza danych eventów. Technicznie może to być cokolwiek; od pamięci przez listę plików, RDBM lub dedykowaną bazę. Np.: https://geteventstore.com/
Event handler

W wąskim znaczeniu - metoda na agregaciu przyjmująca event i na jego podstawie modyfikująca stan obiektu.

Szerzej - coś co słucha eventów i na ich podstawie wykonuje akcje.

Rozróżnia się np. pod względem efektów ubocznych.
Uwaga: agregat to nie to samo co instancja klasy!
Pytania czy idziemy dalej?
Jeszcze trochę o agregacie: …
Kluczowe korzyści:
sekwencyjność modyfikacji agregatu
agregat jest odpowiedzialny za spójność
i tylko agregat
read model
Ponadto:
naturalne wprowadzenie szyny zdarzeń
luźne wiązanie komponentów aplikacji
"wtyczkowalność"
Niezależnie od stosowanej technologii:
AGREGAT TO NIE TABELKA
AGREGAT TO NIE WIERSZ W TABELCE
Agregat może mieć dzieci.
Do dzieci można dostać się wyłącznie przez agregate (query i command).
Faktura i pozycje na FV
Konto, subkonta
Statek i jego trasy
Samochód i jego historia serwisu
Replay

Ponowne (!) odczytanie serii eventów z event store (bazy danych) i zasilenie nimi event handlerów.

Możliwe filtrowanie eventów, np. po czasie (nie starsze niż wczoraj), albo po agregacie (user o id 1).

Nie zawsze wszystkie handlery będą brały udział. Np. chcemy odświeżyć tylko read model, albo chcemy tylko ponowić wysyłkę notyfikacji mailowych.
ALE!

Nie dotyczy to read modelu, tj. możemy:
Read model

Źródło danych dla "query" z CQRS. Przechowuje stan agregatu na "teraz" lub łączy dane z kilku źródeł.
Celem jest odciążenie event store oraz przyspieszenie części prezentacyjnej aplikacji.
Uaktualniany na podstawie eventów.
Wydarzenie dot. jednego agregatu mogą wpływać na kilka obiektów w read modelu (lub na żaden).
select * from invoice_items;
Axon - implementacja CQRS/ES dla Javy.

Dostarcza fundamentów ułatwiających
(i wymuszających) strukturyzowanie aplikacji wokół w/w pryncypiów.
Np.:
AbstractAnnotatedAggregateRoot
@EventSourcedMember
@EventSourcingHandler
@CommandHandler
@TargetAggregateIdentifier
i 10tki innych
Pierwszorzędnym obiektem w Axon jest AggregateRoot.
Integracja ze Spring - AR może być prototype beanem (pozwala na wstrzyknięcie serwisów domenowych).
Kiedy odczytywany jest event Axon wywołuje metody AR oznaczone adnotacją i pasujące do typu tego eventu.

To metoda @EventSourcingHandler odpowiedzialna jest za modyfikację stanu (zapisanie danych z eventu).
AR emituje eventy (metoda apply()) - zapewnia to spójność strumienia zdarzeń.
Dzięki temu można ograniczyć liczbę eventów dot. jednego agregatu.
Klient emituje komendę na szynę (commandBus).


Komenda to zwykłe POJO + @TargetAggregateIdentifier
Axon szuka jednego commandHandlera.

(czyli metody oznaczonej @CommandHandler)
CommandHandler ładuje agregat z "write" modelu (ze strumienia eventów) i wywołuje na nim pseudo-setter.
public void setTitle(String title){
if(!this.title.equals(title))
apply(new TitleSetEvent(this.id, title, ...);
}
Od tego momentu Axon zajmuje się eventem.
Najpierw wywołuje pasujący (ale tylko jeden) @EventSourcingHandler na emitującym agregacie.

Potem wywołuje metody na @EventSourcedMember, czyli dzieciach agregatu.
Uwaga: dzieci muszą sprawdzić czy event ich dotyczy.

Następnie notyfikowane są poza-agregatowe @EventHandler.
PROCES MODYFIKACJI STANU AGREGATU
Konsekwencją - dodanie pola do agregatu wymagania trochę pisania:
POJO z komendą
POJO z eventem
metoda na command handler
metoda (setter) na AR
event handler na AR
test (given-when-then)
Command bus

Zwykła nudna szyna komend.
Jest kilka implementacji.
Można zakładać interceptory.
Interceptory??
Pre-procesory komend. Np.:

BeanValidationInterceptor (JSR-303)
LoggingInterceptor
AuditingInterceptor

Można samemu napisać - interfejs ma jedną metodę
Komendy można wysyłać synchronicznie - czekając na ich wynik (np. by zalogować wyjątek albo odrzucić wiadomość z RMQ)
lub asynchronicznie korzystając z AsynchronousCommandBus
(CommandBus + Executor)
Event bus

Ponownie - plain old bus.
Axon dostarcza kilka implementacji:
synchroniczna inVM
async inVM
rozproszona po AMQP
Event handler

Klasa inna niż agregat subsktybująca eventBus.
Musi zawierać metody @EventHandler.

Axon pozwala grupować je w "klastry".
(zawsze jest jakiś klaster - domyślnie obejmuje wszystkie EH)

Na przykład:
Axon provides the ReplayingCluster, a wrapper around another Cluster implementation that adds the replay capability
Eventy stream ma postać tabeli w RDBMS.

Można stosować też Mongo (ale po co?)

Domyślna serializacja - XStream.

Axon wspiera event upcasting (upgrade eventów)
i wersjonowanie eventów.
SWOT
Axon wymusza podział aplikacji na warstwy


(czyli słownik)
Ta prezentacja była sponsorowana przez:
literkę „
Q”,
ligaturę „fl” & ligaturę fi.
Replay w Axon polega na kolejnym odczytywaniu eventów z bazy i przekazywaniu ich event handlerom.
Uwaga: W przypadku wyjątku przetwarzanie zostanie przerwane!
Historia obiektów do odzyskania (as-of-timestamp)

Za darmo PubSub

Generalnie: to samo co ogólnie CQRS

ALE
Pottrzeba pisać dużo POJOs, dla prostych funkcjonalności.

Np. dodanie pola => 6 FP
Dodatkowe complexity
Testy jednostkowe wymagają setUp:
albo fixture (by Axon)
albo w pełni działający eventStore
Aczkolwiek są proste implementacje ES:
na plikach
w pamięci
Utrudnienie psucia aplikacji dzięki rozdzieleniu odpowiedzialności
(O)
Plugability: dzięki PubSub łatwo wpinać komponenty
(O)
Stan aplikacji jest wyłącznie w eventStore. Dzięki temu w każdej chwili można przebudować read model (replay)
(O)
W związku z pracochłonnością jest ryzyko, że Axon będzie "omijany"
(T)
Dodana zależność + complexity
(T)
Steep
(er)
learning curve
(T)
Full transcript