Architetture distribuite a eventi: sono adatte al mio progetto? Una rapida introduzione ai vantaggi che possiamo ottenere dall'adozione di una architettura a microservizi guidata dagli eventi. Quali sono i problemi che tipicamente affliggono i sistemi software complessi? Quali di questi problemi possono risolti adottando un approccio distribuito? Che complessità dobbiamo affrontare nello sviluppo di applicazioni distribuite? Cercheremo di sviscerare questi e altri dubbi relativi all'implementazione di sistemi event-driven distribuiti.

1. Architetture distribuite a
eventi: sono adatte al mio
progetto?
AxonIQ Italia Community, 24 Febbraio

2. Agenda
● Introduzione ai sistemi distribuiti
● Evoluzione, non Rivoluzione
● I benefici dell'introduzione degli eventi in una architettura a microservizi
● Domain Driven Design
● Il pattern CQRS : Command Query Responsibility Separation
● La location transparency

3. Sistema distribuito
Non installato in un unico modulo, ma con più moduli, distribuiti normalmente su
diverse istanze, comunicanti attraverso la rete.
+ Scalabilità
+ Robustezza
+ Alta disponibilità
+ Affidabilità dei dati

4. Presupposti di un sistema distribuito
● La rete è affidabile
● La latenza della comunicazione è zero
● L’ampiezza di banda è infinita
● La rete è sicura
● Trasportare i dati non ha costo
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

5. Evoluzione, non Rivoluzione

6. Evoluzione, non Rivoluzione
Monolith
● facilità di scrittura e di analisi del codice
● aiuta la fase di debug
● è più semplice da distribuire, non richiede CI-CD complesse
● è più adatto a team di piccole dimensioni
Dividendo il codice in moduli funzionali ci si prepara a una evoluzione, e a poterli
scomporre. Ma bisogna fare attenzione a non creare una Big Ball of Mud.

7. Evoluzione, non Rivoluzione
Microservices
+ unità logiche indipendenti
+ riducono la complessità del modello

8. Evoluzione, non Rivoluzione

9. Evoluzione, non Rivoluzione

10. I vantaggi dei Microservices
● unità indipendenti, facili da modificare ed evolvere a passi
● favorisce un approccio Agile
● favoriscono la scalabilità
● riusabilità del codice/funzionalità
● zero-downtime

11. Gli svantaggi dei Microservizi
● complessità essenziale data dalla architettura
● incremento dei costi
● bisogna essere “alti abbastanza”

12. $

13. Microservices vs Monoliths
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

14. Microservizi?
“Microservices architectures buy you options”
James Lewis
Il nostro settore tende a concentrarsi sulla tecnologia anziché sul risultato
Si dovrebbero usare i microservizi come mezzo per ottenere un risultato desiderato
piuttosto che per il bene di usare una nuova tecnologia

15. Funzionalità, non dati

16. DDD - Domain Driven Design
Domain Driven Design ci permette di affrontare la complessità di un dominio, dando
strumenti per migliorare i nostri progetti.

17. Modelli Complessi
“Astrazione di alcuni concetti del dominio, che può essere usato
per risolvere problemi relativi al dominio.”
“Se insegui due conigli, non ne prenderai nessuno”

18. Una comunicazione più efficace
Ubiquitous Language
un linguaggio comune e rigoroso, essere basato sul modello di dominio utilizzato,
che non presenti ambiguità.

19. DDD - Domain Driven Design
Bounded Context
definisce una parte specifica del Modello di Dominio in cui oggetti specifici hanno
significato coerente e caratteristiche distintive.

20. DDD - Bounded Contexts
1. definisci il modello e le cose importanti per la risoluzione del problema
2. mentre definisci il modello, definisci dei confini
"dove e' utile? dove si può applicare?" "dove non si deve applicare?".
3. mantieni concettualmente coerente il tuo modello all'interno dei confini definiti :
definire le parole usate nel modello è molto importante
4. fai in modo che le definizioni non siano influenzate da idee o concetti appartenenti
ad altri bounded context

21. DDD - Domain Driven Design
Aggregato
Descrive le regole e le relazioni di un oggetto. Raggruppa oggetti che devono poter
lavorare insieme e condividono un modello comune, per offrire cambi di stato
consistenti durante il loro ciclo di vita, che possiamo considerare un solo oggetto
quando guardiamo di cambiamenti sui dati.

22. Usare bene gli strumenti
Il modello non deve essere troppo grande
Per quali classi di problemi è effettivamente ottimizzato il modello?
Come affrontiamo i requisiti non funzionali?
Cosa succede se un servizio deve interagire con più di un aggregato?

23. Definizione di CQRS
Command-Query Responsibility Separation è un pattern architetturale che divide
una applicazione in due parti distinte:
● una dedicata a processare comandi (commands),
● un’altra responsabile a fornire informazioni (queries).

24. CQRS Building Blocks
Command
Un'espressione di intenzione di un'azione di modifica nel dominio.
Query
Una richiesta di informazioni o di stato.

25. Command-Query Responsibility Separation
Commands Queries
UI / API

26. Command Model Query Model / Projections
Due Modelli
• Esecuzione delle attività.
• Contiene operazioni.
• Contiene solo le informazioni
necessarie all’esecuzione delle
operazioni e per prendere decisioni.
• Si occupa di modellare le informazioni.
• salvate nella forma nella quale sono
richieste.
• Denormalizzate / “table-per-view”

27. Sincronizzazione dei Modelli
Le modifiche dei dati richieste dai Command dovrebbero essere visibili nel modello
di Query.
Alternative:
• Shared data source
• Stored procedures
• Architetture Event-Driven

28. CQRS
UI / API
Events
Command
Model
Query Model
Commands Queries
Commands Queries

29. Event driven
Evento
Oggetto che contiene una notifica che qualcosa di importante è successo all'interno
del dominio.

30. I compromessi delle architetture ad eventi
Perdita di controllo sul flusso dell’applicazione
Accettare la eventual consistency
I dati ridondanti non sono un problema

31. CQRS Command Model
(Aggregate, Entity,
Value Object, etc)
Command
Event
Query
Projections
(Aggregate, Entity,
Value Object, etc)

32. Command
model
Query
model
Client
Events
Commands Queries
DDD aggregates + CQRS give great guidance
for potential microservices boundaries

33. Parola d’ordine: disaccoppiare
Location transparency
è il concetto che impone che un componente non abbia bisogno di sapere dove
risiede un altro elemento per comunicare con esso.
- implementata utilizzando i concetti di messaggistica.

34. Location transparency
A Component should not be aware, nor make any
assumptions, of the location of Components it
interacts with
Un componente non deve essere a conoscenza sulla location dei
componenti con il quale interagisce.
La location transparency inizia con un ottimo disegno delle API
(ma non conclude qui)

35. Architetture distribuite a eventi: sono adatte al
mio progetto?
DDD
CQRS
EVENTI
approccio evolutivo
asincronicità
scalabilità
performance
it depends
architettura distribuita
AGILE

36. Grazie.
corrado.musumeci@axoniq.io
@corradomusumeci
/in/corradomusumeci/