[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al mio progetto?
0 likes8 views
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.
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al mio progetto?
- 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 bene鍖ci 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 + Af鍖dabilit dei dati
- 4. Presupposti di un sistema distribuito La rete 竪 af鍖dabile La latenza della comunicazione 竪 zero Lampiezza di banda 竪 in鍖nita La rete 竪 sicura Trasportare i dati non ha costo https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
- 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
- 10. I vantaggi dei Microservices unit indipendenti, facili da modi鍖care 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
- 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湛 ef鍖cace 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 de鍖nisce una parte speci鍖ca del Modello di Dominio in cui oggetti speci鍖ci hanno signi鍖cato coerente e caratteristiche distintive.
- 20. DDD - Bounded Contexts 1. de鍖nisci il modello e le cose importanti per la risoluzione del problema 2. mentre de鍖nisci il modello, de鍖nisci dei con鍖ni "dove e' utile? dove si pu嘆 applicare?" "dove non si deve applicare?". 3. mantieni concettualmente coerente il tuo modello all'interno dei con鍖ni de鍖niti : de鍖nire le parole usate nel modello 竪 molto importante 4. fai in modo che le de鍖nizioni non siano in鍖uenzate 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. De鍖nizione di CQRS Command-Query Responsibility Separation 竪 un pattern architetturale che divide una applicazione in due parti distinte: una dedicata a processare comandi (commands), unaltra responsabile a fornire informazioni (queries).
- 24. CQRS Building Blocks Command Un'espressione di intenzione di un'azione di modi鍖ca 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 allesecuzione 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 modi鍖che 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 noti鍖ca che qualcosa di importante 竪 successo all'interno del dominio.
- 30. I compromessi delle architetture ad eventi Perdita di controllo sul 鍖usso dellapplicazione 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 dordine: 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