Axon Framework - Dal monolite ai microservizi con un approccio evolutivo

Axon Framework
Dal monolite ai microservizi con un approccio evolutivo

Sara Pellegrini
Software Engineer AxonIQ
Chi sono
sara@axoniq.io
@_sara_p_
sarapellegrini
https://www.linkedin.com/in/
sara-pellegrini-55a37913/

Di cosa parleremo
• Monolite vs Big Ball of Mud
• Monolite vs Microservizi
• CQRS
• Command Model
• Projections
• Axon Framework
• Event Sourcing
• AxonDB
• Location Transparency
• AxonHub

Monolite
St Breock Downs Monolith -
www.cornwalls.co.uk

Architecture a layer
Interfaccia grafica
Layer dei servizi
Layer di accesso ai dati
Modellodeldominio

Modellodel
dominio
Le applicazioni monolitiche, crescendo nel tempo,
spesso degenerano nella big ball of mud

Source: http://www.sabisabi.com/images/DungBeetle-on-dung.JPG

“
”
[…] the microservice architectural style is
an approach to developing a single
application as a suite of small services, each
running in its own process and
communicating with lightweight
mechanisms […]
I microservizi
Martin Fowler

Il percorso verso i microservizi
Microservices system
Almost all the cases where I've heard of a
system that was built as a microservice system
from scratch, it has ended up in serious trouble.
Monoliths
Almost all the successful microservice stories
have started with a monolith that got too big
and was broken up
Martin Fowler
Source: http://martinfowler.com/bliki/MonolithFirst.html

Source: http://martinfowler.com/bliki/MonolithFirst.html

I monoliti non sono tutti uguali
St Breock Downs Monolith -
www.cornwalls.co.uk
Source: http://www.sabisabi.com/images/DungBeetle-on-dung.JPG

Agilità Scalabilità
Complessità
addizionale

Command Query Responsibility Segregation
Command
model
Projections
Client
Eventi
Comandi Queries

“Normale” QUERY SQL
22 JOINS 6 SUBQUERIES

Architecture a layer
Interfaccia grafica
Layer dei servizi
Layer di accesso ai dati
Modellodeldominio
Method invocation
Cache Worker
pools
Web
Cache
Session
replication
Distributed 2nd level
cache
Query
Cache

Gli aggregati rappresentano i
limiti della consistenza.
Se necessario, possono esistere
dei riferimenti tramite ID tra gli
aggreati, ma senza alcuna
garanzia di integrità
referenziale.
I clients non possono agire
arbitrariamente su tutti gli
oggetti. Possono farlo solo
attraverso l’aggregate root.
Il modello di scrittura

Il modello di lettura
Projections
E’ un modello ottimizzato per le
specifiche esigenze progettuali di
lettura dei dati.
Tipicamente vengono create molte
projections separate invece di un
unico grande modello.

Command
model
Projections
Client
Eventi
Comandi Queries
Questa struttura rende
naturale la suddivisione dei
vari componenti in diversi
microservizi

Location transparency
A Component should not be aware, nor make any
assumptions, of the location of Components it
interacts with
Un componente non deve né essere a conoscenza né fare alcuna
assunzione rispetto a dove si trovano i componenti coi quali interagisce.
La location transparency parte da un corretto design delle API

Axon Framework
Libreria che semplifica l’implementazione di applicazioni Java
basate su DDD, CQRS e ES

Comandi
public class ConfermaOrdine {
@TargetAggregateIdentifier
private UUID ordineId;
public ConfermaOrdine(UUID ordineId) {
this.ordineId = ordineId;
}
public UUID ordineId() {
return this.ordineId;
}
}
Un comando è la richiesta di
effettuare un’operazione.

Inviare comandi
@RestController
public class OrdineController {
@Autowired
private CommandGateway commandGateway;
@PostMapping("ordine/{id}/conferma")
public void confermaOrdine(@PathVariable("id")UUID id) {
commandGateway.send(new ConfermaOrdine(id));
}
}

Command handler
@Aggregate
public class Ordine {
@AggregateIdentifier private UUID ordineId;
@CommandHandler
void handle(ConfermaOrdine cmd) {
...
}
....

Evento
Un evento è la notifica di qualcosa
di rilevante accaduto nel dominio.
public class OrdineConfermato {
private UUID ordineId;
public ConfermaOrdine(UUID ordineId) {
this.ordineId = ordineId;
}
public UUID ordineId() {
return this.ordineId;
}
}

Event handler
@Component
public class OrdiniOverviewProjection {
@Autowired
private EntityManager entityManager;
@EventHandler
void handle(OrdineConfermato evento) {
/* Recupera l’entità JPA e aggiorna lo stato. */
}
}

Query handler@Component
public class OrdiniQueries {
@Autowired
EntityManager entityManager;
@QueryHandler
public List<Ordine> find(OrdiniConfermati query) {
Query jpaQuery =
entityManager.createQuery("select e from Ordine e where e.confermato = true",
Ordine.class);
jpaQuery.setFirstResult(query.getOffset());
jpaQuery.setMaxResults(query.getLimit());
return jpaQuery.getResultList();
}
}

Event-Driven
Architecture
Event
Sourcing
Event Sourcing
Gli eventi sono l’elemento
base della persistenza del
dominio

Persistenza tradizionale (Non event sourced)
Esempio di implementazione di un sistema di e-commerce
Cosa accade nel databaseCosa accade nell’applicazione
L’utente inizia un nuovo
ordine
Ordine 93771261272

L’utente aggiunge un paio di
occhiali da sole all’ordine
Ordine 93771261272
1 occhiali da sole

scarpe da ginnastica all’ordine
Ordine 93771261272
1 scarpe da ginnastica
1 occhiali da sole

L’utente aggiunge una T-shirt
all’ordine
Ordine 93771261272
1 occhiali da sole
1 T-shirt

L’utente decide che non vuole
comprare le scarpe da
ginnastica e le rimuove
dall’ordine
Ordine 93771261272
1 occhiali da sole
1 T-shirt

L’utente inserisce l’indirizzo e
le informazioni per il
pagamento e conferma
l’ordine Ordine 93771261272
1 T-shirt
1 occhiali da sole
Cliente: Jane
Stato: confermato

Persistenza event sourced

L’utente inizia un nuovo
ordine
OrdineCreato (93771261272)

ProdottoAggiunto(occhiali da sole)
occhiali da sole all’ordine

1 sunglasses
ProdottoAggiunto(scarpe da ginnastica)
scarpe da ginnastica all’ordine

1 sunglasses
ProdottoAggiunto(T-shirt)
L’utente aggiunge una T-shirt
all’ordine

1 sunglasses
ProdottoRimosso(scarpe da ginnastica)
L’utente decide che non vuole
comprare le scarpe da
ginnastica e le rimuove
dall’ordine

1 sunglasses
ProdottoRimosso(scarpe da ginnastica)
OrdineConfermato (Jane)
L’utente inserisce l’indirizzo e
le informazioni per il
pagamento e conferma
l’ordine

• Auditing
• Data mining, analytics
Ragioni tecniche
Ragioni di business
Svantaggi
Perchè usare l’event sourcing
• E’ necessario mantenere il supporto
di tutti gli eventi del passato
• l’Event Store cresce sempre
• Gli eventi rappresentato un’unica fonte di verità
• Semplifica la riproduzione di un
malfunzionamento
• Replay degli eventi per la creazione di nuove
projection o la rigenerazione di quelle esistenti
• Rende esplicito l’intento dell’utente

@Aggregate
public class Ordine {
@AggregateIdentifier UUID ordineId;
private Boolean confermato;
@CommandHandler
void handle(ConfermaOrdine comando) {
if(confermato) {
throw new IllegalStateException("L’ordine è già stato confermato.");
}
apply(new OrdineConfermato(comando.ordineId()));
}
@EventSourcingHandler
void handle(OrdineConfermato evento) {
confermato = true;
}
}

Leggere Eventi Scrivere Eventi
Tutti gli eventi di un determinato
aggregato (event sourced repository)
Tutti gli eventi da un determinato
momento (replay per i read models)
Lettura degli eventi in ordine temporale
Aggiungere nuovi eventi
Inserire eventi in un punto random
Aggiornare gli eventi
Cancellare gli eventi
Queries ad-hoc (per ragioni di
debug, monitoring, supporto)
Event store

AxonDB
• Event Store prodotto da AxonIQ
• Scritto in Java da zero
• Pensato appositamente per l’event sourcing
• Gestisce i file direttamente - non si appoggia a un database
• Fornisce interfaccie aperte basate su HTTP+JSON e gRPC
• Nativamente integrato con Axon Framework

time
Append-only
by design
time
Event-stream
suddiviso in
segmenti
Data Index
Bloom-
filter
In ogni segmento è
possibile ricercare per
aggregate id + seq no
search
La ricerca di eventi va
a ritroso nel tempo

Iniziare a utilizzare AxonDB
• Pagina di prodotto: https://axoniq.io/products/axondb.html
• La Developer Edition è gratuita, può essere scaricata insieme
al manuale di utilizzo.

Vantaggi
• Sistemi in tempo reale
• Polling -> Push
• System integration
• Test funzionali Given-When-Then
• Supporta lo sviluppo di un
monolite strutturato
che possa essere all’occorrenza
facilmente suddiviso in microservizi.
DDD
CQRS
ES
Axon Framework

Suddividere il monolite non è
sempre semplice

Agilità
Complessità addizionale
nella gestione del
"Monolite distribuito"
Scalabilità

Complessità addizionale per la
distribuzione in microservizi di
un sistema ben progettato
Agilità Scalabilità

Location transparency in Axon
@CommandHandler
Componente applicativo
<<interface>>
CommandBus
Si registra a
<<class>>
SimpleCommandBus
implementa
CommandBus – QueryBus e EventBus si comportano analogamente
<<class>>
AsyncCommandBus
implementa
<<class>>
DistributedCommandBus
Client
Invia a
Invia a
implementa

Solo l’intelligenza che serve
dumb smart
Message Broker
Invia Messaggi. L’unico
vantaggio che offre è
l’affidabilità
Enterprise Service Bus
Comprende il contenuto dei
messaggi. È difficile da
configurare e da manutenere
AxonHub
Capisce la differenza fra Eventi, Comandi e
Queries e determina il corretto paradigma di
routing. Non si interessa del contenuto dei
messaggi.

Come iniziare con AxonHub
• Pagina di prodotto: https://axoniq.io/product-
overview/axonhub
• La Developer Edition è gratuita, può essere scaricata insieme
al manuale di utilizzo.

Domande?
Conferenza: 21 settembre - Amsterdam - promo code: Axon.Friend
Event-Driven Microservices Conference by AxonIQ
axoniq.io/conference
Training: 19-20 settembre - Amsterdam
Introduction and advanced features of Axon Framework
axoniq.io/events
Webinar: 7 giugno - online
Microservices with Axon platform - live coding webinar
axoniq.io/webinars

Axon Framework - Dal monolite ai microservizi con un approccio evolutivo

Recommended

Recommended

More Related Content

Similar to Axon Framework - Dal monolite ai microservizi con un approccio evolutivo

Similar to Axon Framework - Dal monolite ai microservizi con un approccio evolutivo (20)

Axon Framework - Dal monolite ai microservizi con un approccio evolutivo