From 785a25495fbacbb86c1e5b9bd0915ede3a983fa3 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 22 Sep 2023 13:05:23 +0200 Subject: [PATCH 01/75] feat: prima bozza di contenuto --- docs/architetture-software/README.md | 89 ++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 docs/architetture-software/README.md diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md new file mode 100644 index 00000000..4e907d07 --- /dev/null +++ b/docs/architetture-software/README.md @@ -0,0 +1,89 @@ +# Architetture Software + +## Una doverosa premessa + +Il termine "architettura software" è un termine che viene utilizzato in maniera molto generica e spesso impropria. In questo documento cercheremo di dare una definizione di architettura software e di descrivere le principali architetture software. + +Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. + +L'argomento è molto vasto e complesso, per cui cercheremo di dare una visione generale, senza entrare troppo nel dettaglio, in quanto ogni singola sezione di questo capitolo potrebbe essere un libro a sé stante. + +## Cos'è l'architettura software? + +Wikipedia ci da uno spunto di partenza: + +> L'architettura software è l'insieme delle strutture necessarie per ragionare su un sistema software e la disciplina per creare tali strutture e sistemi. Ogni struttura comprende elementi software, relazioni tra loro e proprietà di entrambi gli elementi e delle relazioni. + +In parole povere, l'architettura software è l'insieme di tutte le decisioni prese durante la progettazione di un sistema software. + +## Punti chiave dell'architettura software + +L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che sono comuni a tutte le architetture software. + +- **Componenti e moduli**: identifica i principali componenti o moduli del software e descrive le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. +- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficienti. +- **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui gestisce gli errori, ripristina i guasti e si adatta per far fronte all'aumento del carico. +- **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. +- **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. + +In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resista alla prova del tempo. + +## Chi si occupa di architetture software? + +Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua implementazione pratica. Il ruolo va oltre il codice; implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. + +Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere: + +- **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architettonici. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscere più di un linguaggio di programmazione possa aiutare a trovare soluzioni più efficaci. +- **Attitudine al problem-solving**: sono essenziali forti capacità analitiche e di risoluzione dei problemi. Questa figura deve analizzare problemi complessi, identificare soluzioni e prendere decisioni che incidono sulla progettazione complessiva del sistema. +- **Comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. +- **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. +- **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. +- **Conoscenza del business**: comprendere gli obiettivi aziendali e i vincoli del progetto o prodotto è fondamentale. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. +- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere adattabile e aperta a nuove tecnologie e metodologie, nonché capace di rivalutare e adattare l’architettura quando necessario. + +## Ma quindi chi si occupa di architetture software deve essere necessariamente un senior? + +No, non necessariamente. Anche se è vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. + +## Fitness functions + +Il termine _fitness function_ viene spesso adottato quando si parla di architetture evolutive, ovvero architetture software il cui scopo è quello di evolvere nel tempo, adattandosi ai cambiamenti del business e del mercato. Possono essere assimilabili a delle metriche che permettono di valutare quanto un'architettura software sia adatta a raggiungere gli obiettivi prefissati o ad eventuali obiettivi futuri del business. + +Apiumhub nel 2020 ha pubblicato un post sul proprio blog in cui definisce questo concetto in maniera molto chiara: + +> La _fitness functions_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. + +[TODO] Espandere il concetto, triggered vs continous functions + +## Quali sono le principali architetture software? + +Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. Quanto segue è un elenco non esaustivo delle principali architetture software, diventato però nel corso dei decenni uno standard de facto. + +Ad ogni architettura software è associato un elenco contenente i punti chiave che seguono: + +- **Start-up**: Il tempo necessario per implementare questa architettura software e cominciare a sviluppare funzionalità. Potremmo anche definirla come la _time to market_. +- **Costi**: Il costo che si affronta nell'arco della vita di un progetto o un prodotto che implementi questa architettura. +- **Sviluppo e manutenzione**: La facilità con il quale è possibile effettuare modifiche e manutenzione al software. Per semplicità, anche l'aspetto del testing viene incluso in questo punto. +- **Tracciabilità**: La facilità con la quale è possibile individuare problemi o bug all'interno del software. +- **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, quanto dell'impegno tecnico necessario per scalare il software. +- **Performance**: La velocità con la quale il software è in grado di elaborare i dati e restituire una risposta o rispondere ad un'esigenza. + +Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato in questo elenco. + +I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore logicamente migliore per il punto chiave in questione, mentre per _basso_ si intende il valore logicamente peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. + +### Monolite + +Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, in quanto tutti i componenti sono all'interno dello stesso processo. + +Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. + +- **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Esempi principali sono Ruby on Rails, Django, Spring Boot, Laravel, ecc. +- **Costi**: 2. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Sviluppo e manutenzione**: 4. Il monolite è l'architettura software più semplice da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. Inoltre, essendo un'architettura molto diffusa, è facile trovare persone che la conoscano e che possano aiutare a sviluppare e mantenere il software. +- **Tracciabilità**: 4. Essendo tutti i componenti parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. +- **Scalabilità**: 1. Il monolite è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur notevoli nelle prime fasi di vita del software, tendono a degradare nel tempo. + +[TODO] Layered architecture, modular monolith, microkernel, microservices, service-based, service-oriented, event-driven, space-based. From 29fe3e0cd7df31261912dec40c8c9a21566bb199 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 22 Sep 2023 13:56:12 +0200 Subject: [PATCH 02/75] feat: aggiunto il monolite modulare --- docs/architetture-software/README.md | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 4e907d07..d6366d4c 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -79,11 +79,28 @@ Il monolite è un'architettura software in cui tutte le funzionalità sono svilu Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. +Solitamente questa architettura viene identificata anche come _Layered Architecture_. + - **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Esempi principali sono Ruby on Rails, Django, Spring Boot, Laravel, ecc. -- **Costi**: 2. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. -- **Sviluppo e manutenzione**: 4. Il monolite è l'architettura software più semplice da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. Inoltre, essendo un'architettura molto diffusa, è facile trovare persone che la conoscano e che possano aiutare a sviluppare e mantenere il software. +- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplice da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. - **Tracciabilità**: 4. Essendo tutti i componenti parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. -- **Scalabilità**: 1. Il monolite è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Scalabilità**: 1. Il monolite è tra le architetture software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur notevoli nelle prime fasi di vita del software, tendono a degradare nel tempo. -[TODO] Layered architecture, modular monolith, microkernel, microservices, service-based, service-oriented, event-driven, space-based. +### Monolite Modulare + +Il monolite modulare è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto, ma con la differenza che il codice è organizzato in moduli. Questi moduli possono essere sviluppati e distribuiti in maniera indipendente, ma sono comunque parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. + +I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa architettura al concetto di _architettura esagonale_, tanto che alle volte i due termini vengono usati indistintamente per intendere lo stesso concetto. + +Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. + +- **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. +- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Sviluppo e manutenzione**: 5. Rispetto a un monolite _classico_, il monolite modulare è più semplice da sviluppare e mantenere, in quanto i moduli hanno un compito ben definito e sono quanto più possibile indipendenti tra di loro. +- **Tracciabilità**: 2. Compattando i moduli in un unico blocco, è più difficile individuare la porzione di codice che ha generato un problema o un bug in quanto solitamente il codice dei singoli moduli viene minificato o comunque ottimizzato per la produzione. +- **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Performance**: 1. La performance del monolite modulare presenta le stesse falle del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. + +[TODO] microkernel, microservices, service-based, service-oriented, event-driven, space-based. From aed57e5a4ff588c3292123a00a04d7f516e52420 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 22 Sep 2023 14:05:10 +0200 Subject: [PATCH 03/75] feat: aggiunto architettura a microkernel --- docs/architetture-software/README.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index d6366d4c..a8248543 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -92,7 +92,7 @@ Solitamente questa architettura viene identificata anche come _Layered Architect Il monolite modulare è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto, ma con la differenza che il codice è organizzato in moduli. Questi moduli possono essere sviluppati e distribuiti in maniera indipendente, ma sono comunque parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. -I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa architettura al concetto di _architettura esagonale_, tanto che alle volte i due termini vengono usati indistintamente per intendere lo stesso concetto. +I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa architettura al concetto di _architettura esagonale_, tanto che alle volte i due termini vengono usati indistintamente per intendere lo stesso concetto. La forza di questa architettura è comunque la possibilità, seppur da tenere sotto controllo, di far comunicare tra di loro i moduli. Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. @@ -103,4 +103,18 @@ Da non confondersi con altre architetture, in questo caso i moduli sono parte de - **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 1. La performance del monolite modulare presenta le stesse falle del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. -[TODO] microkernel, microservices, service-based, service-oriented, event-driven, space-based. +## Architettura a Microkernel + +Chiamata anche _architettura a plugin_, si compone essenzialmente di un nucleo centrale che si occupa di gestire le comunicazioni tra i vari componenti, che sono sviluppati e distribuiti come plugin. +Questi plugin possono essere sviluppati e distribuiti in maniera indipendente, ma funzionando attorno ad un nucleo centrale, faranno sempre parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. + +Il concetto principale attorno a questa architettura è l'indipendenza totale tra i plugin. Per definizione, nessun plugin dovrebbe avere come dipendenza un altro plugin. + +- **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere un po' di tempo. +- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sul quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. +- **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è mediamente complesso. L'isolamento dei plugin aiuta con il testing, ma la correlazione col nucleo centrale a volte può rallentare il processo di tracciamento. +- **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, che non ne permette la _scalabilità orizzontale_. +- **Performance**: 4. Processi di comunicazione semplice e isolabilità rendono questa architettura molto performante. + +[TODO] microservices, service-based, service-oriented, event-driven, space-based. From cef6b408dad942f2c8af57e8a3d517ed321ee92a Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 23 Sep 2023 22:20:09 +0200 Subject: [PATCH 04/75] feat: aggiunti microservizi --- docs/architetture-software/README.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index a8248543..3c8c6be2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -103,7 +103,7 @@ Da non confondersi con altre architetture, in questo caso i moduli sono parte de - **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 1. La performance del monolite modulare presenta le stesse falle del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. -## Architettura a Microkernel +## Microkernel Chiamata anche _architettura a plugin_, si compone essenzialmente di un nucleo centrale che si occupa di gestire le comunicazioni tra i vari componenti, che sono sviluppati e distribuiti come plugin. Questi plugin possono essere sviluppati e distribuiti in maniera indipendente, ma funzionando attorno ad un nucleo centrale, faranno sempre parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. @@ -117,4 +117,19 @@ Il concetto principale attorno a questa architettura è l'indipendenza totale tr - **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, che non ne permette la _scalabilità orizzontale_. - **Performance**: 4. Processi di comunicazione semplice e isolabilità rendono questa architettura molto performante. -[TODO] microservices, service-based, service-oriented, event-driven, space-based. +## Microservizi + +La _buzzword_ per eccellenza degli ultimi anni. + +Spesso affiancata alle architetture orientate agli eventi, questa architettura software si compone di un insieme di servizi indipendenti tra di loro, ognuno con un compito ben definito, che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. + +A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio è un'unità di rilascio indipendente dagli altri. + +- **Start-up**: 2. La start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il metodo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. +- **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. +- **Sviluppo e manutenzione**: 2. Il sistema di orchestrazione o coreografia dei microservizi può aggiungere una complessità non indifferente, soprattutto se non si ha esperienza in questo campo. Inoltre, la necessità di comunicare tra i microservizi può aggiungere un ulteriore livello di complessità. +- **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è complesso. L'isolamento dei microservizi aiuta in questo caso, ma la tracciabilità è molto complessa e spesso richiede sviluppi ad hoc di _distributed tracing_ o _open telemetry_. +- **Scalabilità**: 5. La scalabilità è il punto di forza di questa architettura, in quanto ogni microservizio può essere scalato indipendentemente dagli altri. +- **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli microservizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. + +[TODO] service-based, service-oriented, event-driven, space-based. From 0df9aa55af80a2658b4b040c8c529a493f7dcf63 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 26 Sep 2023 21:53:37 +0200 Subject: [PATCH 05/75] chore: aggiunte fitness function + adr + info su posizione architetturale dei componenti --- docs/architetture-software/README.md | 36 +++++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 3c8c6be2..eee77cfb 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -54,7 +54,33 @@ Apiumhub nel 2020 ha pubblicato un post sul proprio blog in cui definisce questo > La _fitness functions_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. -[TODO] Espandere il concetto, triggered vs continous functions +Esempi di fitness function possono essere: punteggio di scalabilità , percentuale di errori, tempo medio di risposta, quantità di messaggi persi dal broker, ecc. + +### Triggered Fitness functions + +Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazione o una persona del QA che esegue determinate attività stabilite. + +Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguite in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentative di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. + +### Continuous Fitness functions + +Le _continuous fitness functions_ (funzioni di fitness _continue_) vengono eseguite in modo continuo sull'ambiente in analisi, tramite raccolta di metriche in tempo reale o comunque a cadenze rapide. Questo tipo di funzioni di fitness sono utili per monitorare il sistema e rilevare eventuali problemi prima che si verifichino, o analizzare dei trend. + +Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazione reale, dall'altro lato ha il difetto di non essere replicabile, in quanto si basa su dati presi dall'ambiente che si sta analizzando (Solitamente quello di produzione). + +## Architecture Decision Records + +Le _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. + +A differenza di una classica documentazione tecnica o di un diagramma, le ADR sono molto più semplici da scrivere e da leggere, in quanto sono composte da pochi elementi: + +- **Titolo**: il titolo della decisione presa. +- **Stato**: lo stato della decisione presa. Solitamente può essere _Proposta_, _Accettata_, _Completata_, _Rifiutata_ o _Sostituita_. +- **Contesto**: il contesto in cui è stata presa la decisione. +- **Decisione**: la decisione presa. +- **Conseguenze**: le conseguenze della decisione presa. + +Le ADR vengono spesso utilizzate nelle aziende in cui si fa leva sul _BDD_ (Behavior Driven Development) per la stesura dei ticket nel proprio sistema di ticketing, puntando ad uno specifico ADR per dare informazioni aggiuntive e contesto a chi legge il ticket. ## Quali sono le principali architetture software? @@ -81,6 +107,8 @@ Trattasi dell'architettura software più semplice da implementare e più diffusa Solitamente questa architettura viene identificata anche come _Layered Architecture_. +In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. + - **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Esempi principali sono Ruby on Rails, Django, Spring Boot, Laravel, ecc. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplice da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. @@ -96,6 +124,8 @@ I moduli devono essere quanto possibile indipendenti tra di loro, il che affianc Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. +In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. + - **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 5. Rispetto a un monolite _classico_, il monolite modulare è più semplice da sviluppare e mantenere, in quanto i moduli hanno un compito ben definito e sono quanto più possibile indipendenti tra di loro. @@ -110,6 +140,8 @@ Questi plugin possono essere sviluppati e distribuiti in maniera indipendente, m Il concetto principale attorno a questa architettura è l'indipendenza totale tra i plugin. Per definizione, nessun plugin dovrebbe avere come dipendenza un altro plugin. +In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. + - **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere un po' di tempo. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sul quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. @@ -125,6 +157,8 @@ Spesso affiancata alle architetture orientate agli eventi, questa architettura s A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio è un'unità di rilascio indipendente dagli altri. +In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (Basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. + - **Start-up**: 2. La start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il metodo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. - **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. - **Sviluppo e manutenzione**: 2. Il sistema di orchestrazione o coreografia dei microservizi può aggiungere una complessità non indifferente, soprattutto se non si ha esperienza in questo campo. Inoltre, la necessità di comunicare tra i microservizi può aggiungere un ulteriore livello di complessità. From 3740b7004278362c69199a4a7f0681bf871e6161 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 27 Sep 2023 16:25:13 +0200 Subject: [PATCH 06/75] chore: corretti typo --- docs/architetture-software/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index eee77cfb..cc6130a9 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -58,15 +58,15 @@ Esempi di fitness function possono essere: punteggio di scalabilità , percentua ### Triggered Fitness functions -Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazione o una persona del QA che esegue determinate attività stabilite. +Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazioni o una persona del QA che esegue determinate attività stabilite. -Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguite in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentative di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. +Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentative di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. ### Continuous Fitness functions Le _continuous fitness functions_ (funzioni di fitness _continue_) vengono eseguite in modo continuo sull'ambiente in analisi, tramite raccolta di metriche in tempo reale o comunque a cadenze rapide. Questo tipo di funzioni di fitness sono utili per monitorare il sistema e rilevare eventuali problemi prima che si verifichino, o analizzare dei trend. -Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazione reale, dall'altro lato ha il difetto di non essere replicabile, in quanto si basa su dati presi dall'ambiente che si sta analizzando (Solitamente quello di produzione). +Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazione reale, dall'altro lato ha il difetto di non essere replicabile, in quanto si basa su dati presi dall'ambiente che si sta analizzando (solitamente quello di produzione). ## Architecture Decision Records @@ -157,7 +157,7 @@ Spesso affiancata alle architetture orientate agli eventi, questa architettura s A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio è un'unità di rilascio indipendente dagli altri. -In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (Basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. +In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. - **Start-up**: 2. La start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il metodo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. - **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. From 3318f63c4260a8f75a06260f78a36cbb1f01cdb5 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 29 Sep 2023 17:05:59 +0200 Subject: [PATCH 07/75] Corretti typo su microservizi + aggiunte SBA --- docs/architetture-software/README.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index cc6130a9..bb0b05f2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -160,10 +160,27 @@ A differenza delle architetture _a singolo blocco_ viste sopra, questa architett In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. - **Start-up**: 2. La start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il metodo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. -- **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. +- **Costi**: 4. Potendo scalare indipendentemente i singoli microservizi, i costi sono contenuti, in quanto è possibile scalare solo i microservizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. - **Sviluppo e manutenzione**: 2. Il sistema di orchestrazione o coreografia dei microservizi può aggiungere una complessità non indifferente, soprattutto se non si ha esperienza in questo campo. Inoltre, la necessità di comunicare tra i microservizi può aggiungere un ulteriore livello di complessità. -- **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è complesso. L'isolamento dei microservizi aiuta in questo caso, ma la tracciabilità è molto complessa e spesso richiede sviluppi ad hoc di _distributed tracing_ o _open telemetry_. +- **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è complesso. L'isolamento dei microservizi aiuta in questo caso, ma la tracciabilità è piuttosto complessa e richiede integrazione di _distributed tracing_ o _open telemetry_. - **Scalabilità**: 5. La scalabilità è il punto di forza di questa architettura, in quanto ogni microservizio può essere scalato indipendentemente dagli altri. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli microservizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. -[TODO] service-based, service-oriented, event-driven, space-based. +## Service-oriented + +Il _service-oriented_ è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. + +Ci si aspetta che i servizi abbiano una costante comunicazione tra di loro e che rispettino dei contratti (interfacce) ben stabilite. Questo tipo di architettura è molto simile a quella dei microservizi, ma con la differenza che i servizi sono solitamente più grandi e con un compito ben definito. + +In questa architettura ogni servizio solitamente ha il proprio database, il proprio back-end e il proprio front-end, anche se ci sono casi in cui il database sia condiviso tra i servizi (In questo caso si suggerisce un utente con accesso alle sole tabelle o schemi di pertinenza), altri in cui il front-end vive in un applicativo separato o, ancora, altri in cui il front-end è unico per tutti i servizi. + +Questa architettura viene spesso indicata come "l'anello mancante" tra il monolite e i microservizi, anche se la dimensione dei servizi e il successivo _decoupling_ sono temi piuttosto complessi da gestire. + +- **Start-up**: 3. La start-up di un'architettura di questo tipo è complessa, ma non quanto quella dei microservizi, anche se molte delle sfide sono simili. +- **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. +- **Sviluppo e manutenzione**: 3. Come per lo start-up, le sfide e le necessità sono simili a quelle dei microservizi, ma essendo entità più grandi, la complessità diminuisce. +- **Tracciabilità**: 4. Testare e tracciare eventuali bug in questa architettura è piuttosto semplice vista la normale dimensione che i servizi hanno. L'isolamento aiuta, e anche qui si suggerisce l'integrazione di _distributed tracing_ o _open telemetry_. +- **Scalabilità**: 4. La scalabilità è il punto di forza di questa architettura, in quanto ogni servizio può essere scalato indipendentemente dagli altri, ma la dimensione degli stessi può rendere più complicato del previsto il processo. +- **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli servizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. + +[TODO] service-oriented, event-driven, space-based. From 102a669ab75eadb9163c55a045dc93afdd3d94e3 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 29 Sep 2023 17:32:20 +0200 Subject: [PATCH 08/75] Aggiunti ultimi riferimenti e conclusioni --- docs/architetture-software/README.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index bb0b05f2..5df3a8fb 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -183,4 +183,18 @@ Questa architettura viene spesso indicata come "l'anello mancante" tra il monoli - **Scalabilità**: 4. La scalabilità è il punto di forza di questa architettura, in quanto ogni servizio può essere scalato indipendentemente dagli altri, ma la dimensione degli stessi può rendere più complicato del previsto il processo. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli servizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. -[TODO] service-oriented, event-driven, space-based. +## Altre architetture e pattern + +Architetture come la _space-based architecture_ vengono utilizzate in contesti specifici e non sono solitamente utilizzate come architetture software di riferimento, di conseguenza vengono citate solo per completezza d'informazione. + +Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà vanno ad intendere un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. + +## Conclusioni + +L'architettura software è un argomento molto vasto e complesso, ma è un argomento che ognuno di noi dovrebbe conoscere e comprendere, in quanto influenza ogni aspetto dello sviluppo software. + +Un'architettura scelta in maniera frettolosa o senza una valutazione attenta può portare a conseguenze disastrose, come ad esempio un sistema che non riesce a gestire il carico di lavoro o che non riesce a soddisfare i requisiti di qualità e scalabilità richiesti. + +## Riferimenti + +La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme. \ No newline at end of file From 34c47b82974cb90475aff42e062bd11f92a053c6 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 29 Sep 2023 17:34:07 +0200 Subject: [PATCH 09/75] Ultime conclusioni --- docs/architetture-software/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 5df3a8fb..0cbeefc0 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -195,6 +195,8 @@ L'architettura software è un argomento molto vasto e complesso, ma è un argome Un'architettura scelta in maniera frettolosa o senza una valutazione attenta può portare a conseguenze disastrose, come ad esempio un sistema che non riesce a gestire il carico di lavoro o che non riesce a soddisfare i requisiti di qualità e scalabilità richiesti. +D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sulle mere valutazioni fatte, che sono generaliste e non applicabili a tutti i contesti, ma di approfondire l'argomento e di valutare con attenzione ogni aspetto, in quanto ogni architettura software ha i suoi pro e i suoi contro, e ogni progetto ha le sue esigenze, e spesso la verità sta nel mezzo o, come piace dire a noi dev, _dipende_. + ## Riferimenti La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme. \ No newline at end of file From e67b8e92b53fba87bf0bd76bb6c8b6434f86dfa4 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 29 Sep 2023 17:36:04 +0200 Subject: [PATCH 10/75] Ultime conclusioni --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 0cbeefc0..d3301319 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -199,4 +199,4 @@ D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sul ## Riferimenti -La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme. \ No newline at end of file +La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme, tra cui O'Reilly e YouTube. \ No newline at end of file From 9f548393bdfe13086dc7bc0a545fb324ec6595c2 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 29 Sep 2023 17:36:25 +0200 Subject: [PATCH 11/75] lint --- docs/architetture-software/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index d3301319..d18ca2a8 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -195,8 +195,8 @@ L'architettura software è un argomento molto vasto e complesso, ma è un argome Un'architettura scelta in maniera frettolosa o senza una valutazione attenta può portare a conseguenze disastrose, come ad esempio un sistema che non riesce a gestire il carico di lavoro o che non riesce a soddisfare i requisiti di qualità e scalabilità richiesti. -D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sulle mere valutazioni fatte, che sono generaliste e non applicabili a tutti i contesti, ma di approfondire l'argomento e di valutare con attenzione ogni aspetto, in quanto ogni architettura software ha i suoi pro e i suoi contro, e ogni progetto ha le sue esigenze, e spesso la verità sta nel mezzo o, come piace dire a noi dev, _dipende_. +D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sulle mere valutazioni fatte, che sono generaliste e non applicabili a tutti i contesti, ma di approfondire l'argomento e di valutare con attenzione ogni aspetto, in quanto ogni architettura software ha i suoi pro e i suoi contro, e ogni progetto ha le sue esigenze, e spesso la verità sta nel mezzo o, come piace dire a noi dev, _dipende_. ## Riferimenti -La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme, tra cui O'Reilly e YouTube. \ No newline at end of file +La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme, tra cui O'Reilly e YouTube. From fc0ba1824ac5704be3266721e53e4a51dc3970a4 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 30 Sep 2023 18:10:01 +0200 Subject: [PATCH 12/75] chore: Aggiunti appunti sull'utilizzo delle fitness functions --- docs/architetture-software/README.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index d18ca2a8..7aa6dd05 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -62,12 +62,21 @@ Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentative di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. +Queste funzioni di fitness vengono spesso lanciate durante una _pipeline_ di distribuzione, in modo da intercettare eventuali variazioni prima che il software venga rilasciato in produzione. + +Questo tipo di _fitness function_ richiedono solitamente più manutenzione rispetto alle _continuous fitness functions_, in quanto devono essere aggiornate durante la vita del software, in base alle modifiche che vengono apportate. + +Alcuni esempi sono i test unitari, i test di integrazione, ecc. + ### Continuous Fitness functions Le _continuous fitness functions_ (funzioni di fitness _continue_) vengono eseguite in modo continuo sull'ambiente in analisi, tramite raccolta di metriche in tempo reale o comunque a cadenze rapide. Questo tipo di funzioni di fitness sono utili per monitorare il sistema e rilevare eventuali problemi prima che si verifichino, o analizzare dei trend. Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazione reale, dall'altro lato ha il difetto di non essere replicabile, in quanto si basa su dati presi dall'ambiente che si sta analizzando (solitamente quello di produzione). +Queste funzioni di fitness vengono spesso lanciate in un ambiente di produzione, in modo da avere contezza del reale contesto nel quale vengono eseguite. + +Alcuni esempi sono il monitoraggio dei tempi medi di risposta, il monitoraggio dei messaggi inviati e ricevuti in una coda, ecc. ## Architecture Decision Records Le _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. From a291a733fca152b3251100d76a2bf2d67e6f7117 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 12:31:08 +0200 Subject: [PATCH 13/75] Update docs/architetture-software/README.md Co-authored-by: Simone Gizzi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 7aa6dd05..3d827ea2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -21,7 +21,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che sono comuni a tutte le architetture software. - **Componenti e moduli**: identifica i principali componenti o moduli del software e descrive le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. -- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficienti. +- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. - **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui gestisce gli errori, ripristina i guasti e si adatta per far fronte all'aumento del carico. - **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. - **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. From 46fb016d57dc07a9731b8e8c0af9bb5319fe2eb8 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 12:31:26 +0200 Subject: [PATCH 14/75] Update docs/architetture-software/README.md Co-authored-by: Simone Gizzi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 3d827ea2..48fde3c2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -26,7 +26,7 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide - **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. - **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. -In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resista alla prova del tempo. +In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resistano alla prova del tempo. ## Chi si occupa di architetture software? From f3a0ad79a37b5fc798c68bf234cab0d9e7cf15f7 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 12:41:45 +0200 Subject: [PATCH 15/75] chore: cosmetics --- docs/architetture-software/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 48fde3c2..31f5f014 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -60,11 +60,11 @@ Esempi di fitness function possono essere: punteggio di scalabilità , percentua Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazioni o una persona del QA che esegue determinate attività stabilite. -Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentative di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. +Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentativo di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. Queste funzioni di fitness vengono spesso lanciate durante una _pipeline_ di distribuzione, in modo da intercettare eventuali variazioni prima che il software venga rilasciato in produzione. -Questo tipo di _fitness function_ richiedono solitamente più manutenzione rispetto alle _continuous fitness functions_, in quanto devono essere aggiornate durante la vita del software, in base alle modifiche che vengono apportate. +Questo tipo di _fitness function_ richiede solitamente più manutenzione rispetto alle _continuous fitness functions_, in quanto deve essere aggiornato durante la vita del software, in base alle modifiche che vengono apportate. Alcuni esempi sono i test unitari, i test di integrazione, ecc. From a540f38ed9173aac36ef489e88ffdbf7135bec8e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 14:13:32 +0200 Subject: [PATCH 16/75] chore: cosmetics --- docs/architetture-software/README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 31f5f014..4505f849 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -77,6 +77,7 @@ Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazion Queste funzioni di fitness vengono spesso lanciate in un ambiente di produzione, in modo da avere contezza del reale contesto nel quale vengono eseguite. Alcuni esempi sono il monitoraggio dei tempi medi di risposta, il monitoraggio dei messaggi inviati e ricevuti in una coda, ecc. + ## Architecture Decision Records Le _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. From 94ca892ce9162e031b2e3d39812e1e8b2d21725e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:23:40 +0200 Subject: [PATCH 17/75] Update docs/architetture-software/README.md Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 4505f849..6c1fa4b8 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -2,7 +2,7 @@ ## Una doverosa premessa -Il termine "architettura software" è un termine che viene utilizzato in maniera molto generica e spesso impropria. In questo documento cercheremo di dare una definizione di architettura software e di descrivere le principali architetture software. +Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. From e566aba7d7af7897ed37eb098d7995a6b891dc06 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:24:29 +0200 Subject: [PATCH 18/75] Update docs/architetture-software/README.md Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 6c1fa4b8..e2f053bd 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -6,7 +6,7 @@ Il termine "architettura software" viene spesso utilizzato in maniera molto gene Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. -L'argomento è molto vasto e complesso, per cui cercheremo di dare una visione generale, senza entrare troppo nel dettaglio, in quanto ogni singola sezione di questo capitolo potrebbe essere un libro a sé stante. +L'argomento è molto vasto e complesso, per cui proveremo a dare una visione generale, senza entrare troppo nel dettaglio, in quanto ogni singola sezione di questo capitolo potrebbe concretizzarsi in un libro a sé stante. ## Cos'è l'architettura software? From 0310727f288ce0b04d99f89d5d2ed609b98c9691 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:24:39 +0200 Subject: [PATCH 19/75] Update docs/architetture-software/README.md Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index e2f053bd..99a8e7d9 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -18,7 +18,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre ## Punti chiave dell'architettura software -L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che sono comuni a tutte le architetture software. +L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave in comune: - **Componenti e moduli**: identifica i principali componenti o moduli del software e descrive le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. - **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. From 05be41e3ea285098608eef8995c9b13568deb57d Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:25:55 +0200 Subject: [PATCH 20/75] Update docs/architetture-software/README.md Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 99a8e7d9..053a656e 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -20,7 +20,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave in comune: -- **Componenti e moduli**: identifica i principali componenti o moduli del software e descrive le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. +- **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. - **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. - **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui gestisce gli errori, ripristina i guasti e si adatta per far fronte all'aumento del carico. - **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. From 6d82864bf30d99cbae30cfee0ccd3fae2b0d2830 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:26:05 +0200 Subject: [PATCH 21/75] Update docs/architetture-software/README.md Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 053a656e..07a2ead2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -21,7 +21,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave in comune: - **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. -- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati fluiscono tra le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. +- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. - **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui gestisce gli errori, ripristina i guasti e si adatta per far fronte all'aumento del carico. - **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. - **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. From 52e3c9bf2607c4ccae4f929fd971e8593864ed18 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:30:22 +0200 Subject: [PATCH 22/75] Applicazione suggerimenti in blocco Co-authored-by: Angelo Cassano --- docs/architetture-software/README.md | 62 ++++++++++++++-------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 07a2ead2..a234d8b0 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -22,29 +22,29 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide - **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. - **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. -- **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui gestisce gli errori, ripristina i guasti e si adatta per far fronte all'aumento del carico. -- **Attributi di qualità**: soddisfa i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software per queste qualità. +- **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui vengono gestiti gli errori, ripristinati i guasti e organizzati gli adattamenti per far fronte all'aumento del carico. +- **Attributi di qualità**: soddisfano i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software in funzione di queste qualità. - **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resistano alla prova del tempo. ## Chi si occupa di architetture software? -Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua implementazione pratica. Il ruolo va oltre il codice; implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. +Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere: -- **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architettonici. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscere più di un linguaggio di programmazione possa aiutare a trovare soluzioni più efficaci. +- **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architettonici. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscerne più di uno possa aiutare a trovare soluzioni più efficaci. - **Attitudine al problem-solving**: sono essenziali forti capacità analitiche e di risoluzione dei problemi. Questa figura deve analizzare problemi complessi, identificare soluzioni e prendere decisioni che incidono sulla progettazione complessiva del sistema. - **Comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. - **Conoscenza del business**: comprendere gli obiettivi aziendali e i vincoli del progetto o prodotto è fondamentale. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. -- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere adattabile e aperta a nuove tecnologie e metodologie, nonché capace di rivalutare e adattare l’architettura quando necessario. +- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l’architettura quando necessario. ## Ma quindi chi si occupa di architetture software deve essere necessariamente un senior? -No, non necessariamente. Anche se è vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. +No, non necessariamente. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. ## Fitness functions @@ -54,7 +54,7 @@ Apiumhub nel 2020 ha pubblicato un post sul proprio blog in cui definisce questo > La _fitness functions_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. -Esempi di fitness function possono essere: punteggio di scalabilità , percentuale di errori, tempo medio di risposta, quantità di messaggi persi dal broker, ecc. +Esempi di fitness function possono essere: punteggio di scalabilità, percentuale di errori, tempo medio di risposta, quantità di messaggi persi dal broker, ecc. ### Triggered Fitness functions @@ -64,7 +64,7 @@ Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in m Queste funzioni di fitness vengono spesso lanciate durante una _pipeline_ di distribuzione, in modo da intercettare eventuali variazioni prima che il software venga rilasciato in produzione. -Questo tipo di _fitness function_ richiede solitamente più manutenzione rispetto alle _continuous fitness functions_, in quanto deve essere aggiornato durante la vita del software, in base alle modifiche che vengono apportate. +Questo tipo di _fitness function_ richiede solitamente più manutenzione rispetto alle _continuous fitness functions_, poiché deve essere adattato durante la vita del software, in base alle modifiche che vengono apportate. Alcuni esempi sono i test unitari, i test di integrazione, ecc. @@ -105,43 +105,43 @@ Ad ogni architettura software è associato un elenco contenente i punti chiave c - **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, quanto dell'impegno tecnico necessario per scalare il software. - **Performance**: La velocità con la quale il software è in grado di elaborare i dati e restituire una risposta o rispondere ad un'esigenza. -Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato in questo elenco. +Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore logicamente migliore per il punto chiave in questione, mentre per _basso_ si intende il valore logicamente peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. ### Monolite -Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, in quanto tutti i componenti sono all'interno dello stesso processo. +Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, in quanto questi ultimi risiedono all'interno dello stesso processo. -Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. +Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. Solitamente questa architettura viene identificata anche come _Layered Architecture_. In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. -- **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Esempi principali sono Ruby on Rails, Django, Spring Boot, Laravel, ecc. +- **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Fra i principali framework troviamo Ruby on Rails, Django, Spring Boot, Laravel, ecc. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. -- **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplice da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. +- **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplici da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. - **Tracciabilità**: 4. Essendo tutti i componenti parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. -- **Scalabilità**: 1. Il monolite è tra le architetture software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. -- **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur notevoli nelle prime fasi di vita del software, tendono a degradare nel tempo. +- **Scalabilità**: 1. Il monolite è tra le architetture software più difficili da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza, la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur buone nelle prime fasi di vita del software, tendono a degradare nel tempo. ### Monolite Modulare Il monolite modulare è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto, ma con la differenza che il codice è organizzato in moduli. Questi moduli possono essere sviluppati e distribuiti in maniera indipendente, ma sono comunque parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. -I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa architettura al concetto di _architettura esagonale_, tanto che alle volte i due termini vengono usati indistintamente per intendere lo stesso concetto. La forza di questa architettura è comunque la possibilità, seppur da tenere sotto controllo, di far comunicare tra di loro i moduli. +I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa tipologia al concetto di _architettura esagonale_, tanto che a volte i due termini vengono usati indistintamente per intendere lo stesso concetto. La forza di questa architettura è comunque la possibilità, seppur da tenere sotto controllo, di far comunicare tra di loro i moduli. Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. -- **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. +- **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 5. Rispetto a un monolite _classico_, il monolite modulare è più semplice da sviluppare e mantenere, in quanto i moduli hanno un compito ben definito e sono quanto più possibile indipendenti tra di loro. - **Tracciabilità**: 2. Compattando i moduli in un unico blocco, è più difficile individuare la porzione di codice che ha generato un problema o un bug in quanto solitamente il codice dei singoli moduli viene minificato o comunque ottimizzato per la produzione. - **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. -- **Performance**: 1. La performance del monolite modulare presenta le stesse falle del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. +- **Performance**: 1. La performance del monolite modulare presenta le stesse problematiche del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. ## Microkernel @@ -152,12 +152,12 @@ Il concetto principale attorno a questa architettura è l'indipendenza totale tr In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. -- **Start-up**: 4. Essendo una variante del monolite, la start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere un po' di tempo. +- **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere più tempo. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sul quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. - **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è mediamente complesso. L'isolamento dei plugin aiuta con il testing, ma la correlazione col nucleo centrale a volte può rallentare il processo di tracciamento. - **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, che non ne permette la _scalabilità orizzontale_. -- **Performance**: 4. Processi di comunicazione semplice e isolabilità rendono questa architettura molto performante. +- **Performance**: 4. Processi di comunicazione semplici e isolabilità rendono questa architettura molto performante. ## Microservizi @@ -169,43 +169,43 @@ A differenza delle architetture _a singolo blocco_ viste sopra, questa architett In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. -- **Start-up**: 2. La start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il metodo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. +- **Start-up**: 2. Lo start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il protocollo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. - **Costi**: 4. Potendo scalare indipendentemente i singoli microservizi, i costi sono contenuti, in quanto è possibile scalare solo i microservizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. - **Sviluppo e manutenzione**: 2. Il sistema di orchestrazione o coreografia dei microservizi può aggiungere una complessità non indifferente, soprattutto se non si ha esperienza in questo campo. Inoltre, la necessità di comunicare tra i microservizi può aggiungere un ulteriore livello di complessità. - **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è complesso. L'isolamento dei microservizi aiuta in questo caso, ma la tracciabilità è piuttosto complessa e richiede integrazione di _distributed tracing_ o _open telemetry_. -- **Scalabilità**: 5. La scalabilità è il punto di forza di questa architettura, in quanto ogni microservizio può essere scalato indipendentemente dagli altri. +- **Scalabilità**: 5. La scalabilità è il punto di forza di questa architettura, in quanto ogni microservizio può essere replicato indipendentemente dagli altri. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli microservizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. ## Service-oriented Il _service-oriented_ è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. -Ci si aspetta che i servizi abbiano una costante comunicazione tra di loro e che rispettino dei contratti (interfacce) ben stabilite. Questo tipo di architettura è molto simile a quella dei microservizi, ma con la differenza che i servizi sono solitamente più grandi e con un compito ben definito. +Ci si aspetta che i servizi siano in costante comunicazione tra di loro e che rispettino dei contratti (interfacce) precedentemente stabiliti. Questo tipo di architettura è molto simile a quella dei microservizi, ma con la differenza che i servizi sono solitamente più grandi e con un compito ben definito. -In questa architettura ogni servizio solitamente ha il proprio database, il proprio back-end e il proprio front-end, anche se ci sono casi in cui il database sia condiviso tra i servizi (In questo caso si suggerisce un utente con accesso alle sole tabelle o schemi di pertinenza), altri in cui il front-end vive in un applicativo separato o, ancora, altri in cui il front-end è unico per tutti i servizi. +In questa architettura ogni servizio solitamente ha il proprio database, il proprio back-end e il proprio front-end, anche se ci sono casi in cui il database possa essere condiviso tra i servizi (in questo caso si suggerisce di utilizzare un utente dedicato per l'accesso alle singole tabelle o agli schemi di pertinenza), altri in cui il front-end vive in un applicativo separato o, ancora, altri in cui il front-end è unico per tutti i servizi. Questa architettura viene spesso indicata come "l'anello mancante" tra il monolite e i microservizi, anche se la dimensione dei servizi e il successivo _decoupling_ sono temi piuttosto complessi da gestire. -- **Start-up**: 3. La start-up di un'architettura di questo tipo è complessa, ma non quanto quella dei microservizi, anche se molte delle sfide sono simili. -- **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. -- **Sviluppo e manutenzione**: 3. Come per lo start-up, le sfide e le necessità sono simili a quelle dei microservizi, ma essendo entità più grandi, la complessità diminuisce. +- **Start-up**: 3. Lo start-up di un'architettura di questo tipo è complessa, ma non quanto quella a microservizi, anche se molte delle problematiche sono simili. +- **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui lo si ritiene necessario. +- **Sviluppo e manutenzione**: 3. Come per lo start-up, le sfide e le necessità sono simili a quelle dei microservizi, ma trattandosi di entità più grandi, la complessità diminuisce. - **Tracciabilità**: 4. Testare e tracciare eventuali bug in questa architettura è piuttosto semplice vista la normale dimensione che i servizi hanno. L'isolamento aiuta, e anche qui si suggerisce l'integrazione di _distributed tracing_ o _open telemetry_. -- **Scalabilità**: 4. La scalabilità è il punto di forza di questa architettura, in quanto ogni servizio può essere scalato indipendentemente dagli altri, ma la dimensione degli stessi può rendere più complicato del previsto il processo. +- **Scalabilità**: 4. La scalabilità è il punto di forza di questa architettura, in quanto ogni servizio può essere replicato indipendentemente dagli altri, ma la dimensione degli stessi può rendere più complicato del previsto il processo. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli servizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. ## Altre architetture e pattern Architetture come la _space-based architecture_ vengono utilizzate in contesti specifici e non sono solitamente utilizzate come architetture software di riferimento, di conseguenza vengono citate solo per completezza d'informazione. -Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà vanno ad intendere un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. +Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. ## Conclusioni -L'architettura software è un argomento molto vasto e complesso, ma è un argomento che ognuno di noi dovrebbe conoscere e comprendere, in quanto influenza ogni aspetto dello sviluppo software. +L'architettura software è un argomento molto vasto e complesso, materia che ognuno di noi dovrebbe conoscere e comprendere, in quanto influenza ogni aspetto dello sviluppo software. Un'architettura scelta in maniera frettolosa o senza una valutazione attenta può portare a conseguenze disastrose, come ad esempio un sistema che non riesce a gestire il carico di lavoro o che non riesce a soddisfare i requisiti di qualità e scalabilità richiesti. -D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sulle mere valutazioni fatte, che sono generaliste e non applicabili a tutti i contesti, ma di approfondire l'argomento e di valutare con attenzione ogni aspetto, in quanto ogni architettura software ha i suoi pro e i suoi contro, e ogni progetto ha le sue esigenze, e spesso la verità sta nel mezzo o, come piace dire a noi dev, _dipende_. +D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sulle mere valutazioni fatte, che sono generaliste e non applicabili a tutti i contesti, ma di approfondire l'argomento e di valutare con attenzione ogni aspetto, in quanto ogni architettura software ha i suoi pro e i suoi contro, e ogni progetto ha le sue esigenze, e spesso la verità sta nel mezzo o, come piace dire a noi dev: _dipende_. ## Riferimenti From e7d4b961595b5176f67470eff5fe0f810656beb2 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:31:15 +0200 Subject: [PATCH 23/75] Update docs/architetture-software/README.md --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index a234d8b0..14720170 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -80,7 +80,7 @@ Alcuni esempi sono il monitoraggio dei tempi medi di risposta, il monitoraggio d ## Architecture Decision Records -Le _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. +Gli _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. A differenza di una classica documentazione tecnica o di un diagramma, le ADR sono molto più semplici da scrivere e da leggere, in quanto sono composte da pochi elementi: From 3ef0b4bba88e5aa2cefcc1c05a75063461e19512 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 5 Oct 2023 23:49:41 +0200 Subject: [PATCH 24/75] Update docs/architetture-software/README.md --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 14720170..d0e63c31 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -165,7 +165,7 @@ La _buzzword_ per eccellenza degli ultimi anni. Spesso affiancata alle architetture orientate agli eventi, questa architettura software si compone di un insieme di servizi indipendenti tra di loro, ognuno con un compito ben definito, che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. -A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio è un'unità di rilascio indipendente dagli altri. +A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio viene rilasciato in maniera indipendente. In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. From 1cad904cc278ecc6d3b7d24a82c5c07c57f9b4ae Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 6 Oct 2023 01:29:55 +0200 Subject: [PATCH 25/75] chore: cosmetics --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index d0e63c31..e1ac03de 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -2,7 +2,7 @@ ## Una doverosa premessa -Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. +Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. From 7296ad6852962521cd5e30bbe4a73a4dd6a1033c Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 7 Oct 2023 17:19:18 +0200 Subject: [PATCH 26/75] fix: typo in service-oriented e service-based --- docs/architetture-software/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index e1ac03de..f42a81d8 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -176,9 +176,9 @@ In questa architettura ogni microservizio solitamente ha il proprio database e i - **Scalabilità**: 5. La scalabilità è il punto di forza di questa architettura, in quanto ogni microservizio può essere replicato indipendentemente dagli altri. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli microservizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. -## Service-oriented +## Service-based -Il _service-oriented_ è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. +Il _service-based è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. Ci si aspetta che i servizi siano in costante comunicazione tra di loro e che rispettino dei contratti (interfacce) precedentemente stabiliti. Questo tipo di architettura è molto simile a quella dei microservizi, ma con la differenza che i servizi sono solitamente più grandi e con un compito ben definito. @@ -195,7 +195,7 @@ Questa architettura viene spesso indicata come "l'anello mancante" tra il monoli ## Altre architetture e pattern -Architetture come la _space-based architecture_ vengono utilizzate in contesti specifici e non sono solitamente utilizzate come architetture software di riferimento, di conseguenza vengono citate solo per completezza d'informazione. +Architetture come la _space-based architecture_ o la _service-oriented architecture_ vengono utilizzate in contesti specifici e non sono solitamente utilizzate come architetture software di riferimento, di conseguenza vengono citate solo per completezza d'informazione. Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. From 7fea5aa2c993eb9268396d54525a9f73944a0ac0 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 7 Oct 2023 17:19:37 +0200 Subject: [PATCH 27/75] chore: linting --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index f42a81d8..a5af807a 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -178,7 +178,7 @@ In questa architettura ogni microservizio solitamente ha il proprio database e i ## Service-based -Il _service-based è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. +Il _service-based è un'architettura software in cui l'applicativo viene suddiviso in una manciata di servizi (Solitamente da 3 a 12) che comunicano tra di loro attraverso un meccanismo di comunicazione \_solitamente_ asincrono. Ci si aspetta che i servizi siano in costante comunicazione tra di loro e che rispettino dei contratti (interfacce) precedentemente stabiliti. Questo tipo di architettura è molto simile a quella dei microservizi, ma con la differenza che i servizi sono solitamente più grandi e con un compito ben definito. From 3ecae83f5297377ae2ddee05d3fbe16be6006139 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 7 Oct 2023 17:24:33 +0200 Subject: [PATCH 28/75] chore: aggiustamento sezione microservizi con note sul decoupling --- docs/architetture-software/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index a5af807a..36fec995 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -169,6 +169,10 @@ A differenza delle architetture _a singolo blocco_ viste sopra, questa architett In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. +Per definizione i microservizi non dovrebbero comporsi di più di una manciata di endpoint e relative funzioni, in quanto altrimenti si parla più di _service-based architecture_. + +Da notare che il _decoupling_ creato da questa architettura può portare ad un notevole aumento della complessità. + - **Start-up**: 2. Lo start-up di un'architettura di questo tipo è complessa, in quanto è necessario stabilire sistemi di _orchestrazione_ o di _coreografia_ dei microservizi. Inoltre, il tipo di comunicazione (sincrono o asincrono) e il protocollo adottato (HTTP, AMQP, ecc.) devono essere valutati con attenzione. - **Costi**: 4. Potendo scalare indipendentemente i singoli microservizi, i costi sono contenuti, in quanto è possibile scalare solo i microservizi che ne hanno bisogno, e solo nei momenti in cui si ritiene necessario. - **Sviluppo e manutenzione**: 2. Il sistema di orchestrazione o coreografia dei microservizi può aggiungere una complessità non indifferente, soprattutto se non si ha esperienza in questo campo. Inoltre, la necessità di comunicare tra i microservizi può aggiungere un ulteriore livello di complessità. From aa471b422760dcd7aed4b16954a30621e1d3519e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 11 Oct 2023 17:14:59 +0200 Subject: [PATCH 29/75] Update docs/architetture-software/README.md Co-authored-by: Paolo Martinoli <81316809+ugho16@users.noreply.github.com> --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 36fec995..040084c2 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -18,7 +18,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre ## Punti chiave dell'architettura software -L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave in comune: +L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che si applicano nella maggior parte dei casi: - **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. - **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. From 8e2f6244c7c99372e43decd743b570c7fc8266b0 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 11 Oct 2023 17:15:09 +0200 Subject: [PATCH 30/75] Update docs/architetture-software/README.md Co-authored-by: Paolo Martinoli <81316809+ugho16@users.noreply.github.com> --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 040084c2..bf2707b5 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -122,7 +122,7 @@ In questa architettura il database, il back-end e il front-end sono tutti parte - **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Fra i principali framework troviamo Ruby on Rails, Django, Spring Boot, Laravel, ecc. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplici da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. -- **Tracciabilità**: 4. Essendo tutti i componenti parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. +- **Tracciabilità**: 4. Poiché tutti i componenti fanno parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. - **Scalabilità**: 1. Il monolite è tra le architetture software più difficili da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza, la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur buone nelle prime fasi di vita del software, tendono a degradare nel tempo. From 7b551493fc5e270e171d0451947c305a41dc3309 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 11 Oct 2023 17:15:18 +0200 Subject: [PATCH 31/75] Update docs/architetture-software/README.md Co-authored-by: Paolo Martinoli <81316809+ugho16@users.noreply.github.com> --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index bf2707b5..334913dc 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -193,7 +193,7 @@ Questa architettura viene spesso indicata come "l'anello mancante" tra il monoli - **Start-up**: 3. Lo start-up di un'architettura di questo tipo è complessa, ma non quanto quella a microservizi, anche se molte delle problematiche sono simili. - **Costi**: 4. Potendo scalare indipendentemente i singoli servizi, i costi sono contenuti, in quanto è possibile scalare solo i servizi che ne hanno bisogno, e solo nei momenti in cui lo si ritiene necessario. - **Sviluppo e manutenzione**: 3. Come per lo start-up, le sfide e le necessità sono simili a quelle dei microservizi, ma trattandosi di entità più grandi, la complessità diminuisce. -- **Tracciabilità**: 4. Testare e tracciare eventuali bug in questa architettura è piuttosto semplice vista la normale dimensione che i servizi hanno. L'isolamento aiuta, e anche qui si suggerisce l'integrazione di _distributed tracing_ o _open telemetry_. +- **Tracciabilità**: 4. Testare e tracciare eventuali bug in questa architettura è piuttosto semplice vista la normale dimensione dei servizi. L'isolamento aiuta, e anche qui si suggerisce l'integrazione di _distributed tracing_ o _open telemetry_. - **Scalabilità**: 4. La scalabilità è il punto di forza di questa architettura, in quanto ogni servizio può essere replicato indipendentemente dagli altri, ma la dimensione degli stessi può rendere più complicato del previsto il processo. - **Performance**: 4. La performance di questa architettura è legata alla capacità di scalare i singoli servizi. Con una buona configurazione di auto-scaling si possono raggiungere eccellenti risultati, anche se la necessità di mettere in comunicazione, via HTTP, socket o qualsiasi altra forma, una quantità elevata di sistemi può impattare sulle performance. From a2d9d0839f0aca3d56accff767d77efc3595b927 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 11 Oct 2023 17:36:10 +0200 Subject: [PATCH 32/75] chore: aggiunto paragrafo anti-pattern ms db --- docs/architetture-software/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 334913dc..86ffbcb4 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -169,6 +169,8 @@ A differenza delle architetture _a singolo blocco_ viste sopra, questa architett In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. +A differenza delle altre architetture citate, la condivisione del database è da considerarsi un _anti-pattern_, ovvero una pratica da non adottare, in quanto può portare a problemi di _coupling_ tra i microservizi, esattamente l'opposto di quanto si vuole ottenere con questa architettura. + Per definizione i microservizi non dovrebbero comporsi di più di una manciata di endpoint e relative funzioni, in quanto altrimenti si parla più di _service-based architecture_. Da notare che il _decoupling_ creato da questa architettura può portare ad un notevole aumento della complessità. From 32ec990aa3cf8d32208248e9be61e37781bf5009 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 12 Oct 2023 15:59:11 +0200 Subject: [PATCH 33/75] Aggiunta linee guida in CONTRIBUTING.md (#148) --- CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6e6e6ed..3b79e7a6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -42,3 +42,7 @@ git commit -m "feat: Aggiunta nuova pagina" Il libro è, in questo momento, orientato ad un pubblico italiano. Volendo essere accessibile alla platea più ampia possibile, è necessario utilizzare un linguaggio semplice e chiaro, espresso in lingua italiana, per i contenuti, le cartelle, i commit, le Pull Requests, i commenti, ecc. Seppur abituati a scrivere in inglese commit e Pull Requests, richiediamo a chi contribuisce di utilizzare la lingua italiana anche in questi casi, _al netto del `` dei commit_ per seguire i [Conventional Commits](#conventional-commits), che resteranno in inglese. + +## Linee Guida + +Prima di stendere contenuti o proporre delle Pull Request si suggerisce di dare una lettura alle [Linee Guida](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES.md) (E relativo [Cheatsheet](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES-CHEATSHEET.md)) da rispettare quando si interagisce con il repository. From 03d8bd56a72c15d27f764380ef8d64f09a8b3441 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 28 Oct 2023 11:49:12 +0200 Subject: [PATCH 34/75] chore: aggiunto il contesto aziendale + accenno alla cell-based architecture --- docs/architetture-software/README.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 86ffbcb4..4c1ba594 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -16,6 +16,16 @@ Wikipedia ci da uno spunto di partenza: In parole povere, l'architettura software è l'insieme di tutte le decisioni prese durante la progettazione di un sistema software. +## Il contesto aziendale + +Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova, in quanto comprendere questo contesto è fondamentale per individuare una corretta architettura. + +L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. + +Inoltre, l'architettura del software può influenzare la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura di agilità e reattività, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. + +In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettato tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. + ## Punti chiave dell'architettura software L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che si applicano nella maggior parte dei casi: @@ -28,6 +38,7 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resistano alla prova del tempo. + ## Chi si occupa di architetture software? Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. @@ -40,9 +51,9 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. - **Conoscenza del business**: comprendere gli obiettivi aziendali e i vincoli del progetto o prodotto è fondamentale. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. -- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l’architettura quando necessario. +- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. -## Ma quindi chi si occupa di architetture software deve essere necessariamente un senior? +## Ma quindi chi si occupa di architetture software deve essere necessariamente senior? No, non necessariamente. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. @@ -203,6 +214,8 @@ Questa architettura viene spesso indicata come "l'anello mancante" tra il monoli Architetture come la _space-based architecture_ o la _service-oriented architecture_ vengono utilizzate in contesti specifici e non sono solitamente utilizzate come architetture software di riferimento, di conseguenza vengono citate solo per completezza d'informazione. +Una nota importante riguarda la _cell-based architecture_ che si pone come punto di incontro tra i microservizi e la _service-based architecture_. Partendo dal concetto di microservizi, potremmo identificare una _cell_ come un conglomerato di microservizi che rispondono a una necessità di business con una interfaccia unificata. Se si parte invece dal concetto di _service-based_, potremmo identificare una _cell_ come ulteriore scomposizione per facilitarne la manutenzione e la scalabilità. + Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. ## Conclusioni From de44630613d4992dda2e706774f5b1ddb4a90694 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 28 Oct 2023 11:49:40 +0200 Subject: [PATCH 35/75] chore: linting --- docs/architetture-software/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 4c1ba594..682fd624 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -38,7 +38,6 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resistano alla prova del tempo. - ## Chi si occupa di architetture software? Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. From 0a473c4c470036ac0b7ab3447446609c7c3a2285 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 28 Oct 2023 14:31:11 +0200 Subject: [PATCH 36/75] chore: correzione SOA VS SBA --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 682fd624..242a8e7f 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -215,7 +215,7 @@ Architetture come la _space-based architecture_ o la _service-oriented architect Una nota importante riguarda la _cell-based architecture_ che si pone come punto di incontro tra i microservizi e la _service-based architecture_. Partendo dal concetto di microservizi, potremmo identificare una _cell_ come un conglomerato di microservizi che rispondono a una necessità di business con una interfaccia unificata. Se si parte invece dal concetto di _service-based_, potremmo identificare una _cell_ come ulteriore scomposizione per facilitarne la manutenzione e la scalabilità. -Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del service-oriented. +Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del _service-based_. ## Conclusioni From 5684f89c392ad03105b7ba4b4cdaf1f2b85695a2 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 28 Oct 2023 14:34:10 +0200 Subject: [PATCH 37/75] Update docs/architetture-software/README.md Co-authored-by: Paolo Martinoli <81316809+ugho16@users.noreply.github.com> --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 242a8e7f..da6dab8d 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -10,7 +10,7 @@ L'argomento è molto vasto e complesso, per cui proveremo a dare una visione gen ## Cos'è l'architettura software? -Wikipedia ci da uno spunto di partenza: +Wikipedia ci dà uno spunto di partenza: > L'architettura software è l'insieme delle strutture necessarie per ragionare su un sistema software e la disciplina per creare tali strutture e sistemi. Ogni struttura comprende elementi software, relazioni tra loro e proprietà di entrambi gli elementi e delle relazioni. From 11ed5ca6bbefe3637e55b44632f848ff81e38e9e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 30 Oct 2023 14:18:23 +0100 Subject: [PATCH 38/75] chore: Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index da6dab8d..0cb31b72 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -18,7 +18,7 @@ In parole povere, l'architettura software è l'insieme di tutte le decisioni pre ## Il contesto aziendale -Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova, in quanto comprendere questo contesto è fondamentale per individuare una corretta architettura. +Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova, in quanto, uno sviluppo/progetto si inserisce in un contesto aziendale che deve essere tenuto in conto per una più facile integrazione. L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. From 3c32171176024062544c9b09081b73a28f4f5df4 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 30 Oct 2023 14:18:42 +0100 Subject: [PATCH 39/75] chore: Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 0cb31b72..bcbb8774 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -40,7 +40,7 @@ In sostanza, l'architettura software fornisce un approccio strutturato alla cost ## Chi si occupa di architetture software? -Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo per prestazioni, scalabilità e manutenibilità. +Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo in base ai vincoli prestabiliti. Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere: From 135c0572d83fc6dfc5a9b7bca38254929f83418e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 30 Oct 2023 14:20:47 +0100 Subject: [PATCH 40/75] chore: Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index bcbb8774..3bd362ee 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -49,7 +49,7 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. -- **Conoscenza del business**: comprendere gli obiettivi aziendali e i vincoli del progetto o prodotto è fondamentale. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. +- **Conoscenza del business**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. - **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. ## Ma quindi chi si occupa di architetture software deve essere necessariamente senior? From 3b60b10f9c94028a35dd6963b213d3edd7bc8e92 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 17:58:29 +0100 Subject: [PATCH 41/75] Update docs/architetture-software/README.md --- docs/architetture-software/README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 3bd362ee..578d7ee5 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -1,5 +1,3 @@ -# Architetture Software - ## Una doverosa premessa Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. From 6a32f58cc2247c8516ba3c50c54b82db60bd65ab Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 18:12:40 +0100 Subject: [PATCH 42/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 578d7ee5..83435ea4 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -42,7 +42,7 @@ Chi si occupa di architettura del software è di solito una persona con una cert Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere: -- **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architettonici. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscerne più di uno possa aiutare a trovare soluzioni più efficaci. +- **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architetturali. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscerne più di uno possa aiutare a trovare soluzioni più efficaci in modo particolare se aiuta la comprensione dei limiti che i vari contesti pongono. - **Attitudine al problem-solving**: sono essenziali forti capacità analitiche e di risoluzione dei problemi. Questa figura deve analizzare problemi complessi, identificare soluzioni e prendere decisioni che incidono sulla progettazione complessiva del sistema. - **Comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. From cc7046af14a72fd17f5b994221337d9e3ce6d214 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 18:13:32 +0100 Subject: [PATCH 43/75] Update docs/architetture-software/README.md --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 83435ea4..cb3980b7 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -24,7 +24,7 @@ Inoltre, l'architettura del software può influenzare la strategia e gli obietti In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettato tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. -## Punti chiave dell'architettura software +## I diversi aspetti dell'architettura software L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che si applicano nella maggior parte dei casi: From 37bee823f8484cafeb73eaf822f7ea9155d40ff8 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 18:14:22 +0100 Subject: [PATCH 44/75] Apply suggestions from code review Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index cb3980b7..224f0d09 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -106,7 +106,7 @@ Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. Q Ad ogni architettura software è associato un elenco contenente i punti chiave che seguono: -- **Start-up**: Il tempo necessario per implementare questa architettura software e cominciare a sviluppare funzionalità. Potremmo anche definirla come la _time to market_. +- **Start-up**: Il tempo necessario per definire l'architettura software e cominciare a sviluppare funzionalità. Tale tempo non è da sottovalutare poiché potrebbe richiede, in base al contesto aziendale, una serie di procedure che possono essere automatizzate da tools come le `platform engineering tools`. - **Costi**: Il costo che si affronta nell'arco della vita di un progetto o un prodotto che implementi questa architettura. - **Sviluppo e manutenzione**: La facilità con il quale è possibile effettuare modifiche e manutenzione al software. Per semplicità, anche l'aspetto del testing viene incluso in questo punto. - **Tracciabilità**: La facilità con la quale è possibile individuare problemi o bug all'interno del software. From 2dbab2599b9d0026c9a56a635e36ad2610b684de Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 18:18:45 +0100 Subject: [PATCH 45/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 224f0d09..09c75362 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -54,7 +54,7 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere No, non necessariamente. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. -## Fitness functions +## Misurare la bontà di un'architettura Il termine _fitness function_ viene spesso adottato quando si parla di architetture evolutive, ovvero architetture software il cui scopo è quello di evolvere nel tempo, adattandosi ai cambiamenti del business e del mercato. Possono essere assimilabili a delle metriche che permettono di valutare quanto un'architettura software sia adatta a raggiungere gli obiettivi prefissati o ad eventuali obiettivi futuri del business. From c792385db56c43539a2aa9a2aae64cfd02f2f3b9 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 18:19:13 +0100 Subject: [PATCH 46/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 09c75362..1d5e805f 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -111,7 +111,7 @@ Ad ogni architettura software è associato un elenco contenente i punti chiave c - **Sviluppo e manutenzione**: La facilità con il quale è possibile effettuare modifiche e manutenzione al software. Per semplicità, anche l'aspetto del testing viene incluso in questo punto. - **Tracciabilità**: La facilità con la quale è possibile individuare problemi o bug all'interno del software. - **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, quanto dell'impegno tecnico necessario per scalare il software. -- **Performance**: La velocità con la quale il software è in grado di elaborare i dati e restituire una risposta o rispondere ad un'esigenza. +- **Performance**: La velocità con la quale il software è in grado di elaborare i dati per rispondere ad un'esigenza di business. Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. From ed42ee3a2a6edc5b49466133edf036940d91c6b2 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 2 Nov 2023 19:12:24 +0100 Subject: [PATCH 47/75] Update docs/architetture-software/README.md --- docs/architetture-software/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 1d5e805f..876d7a44 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -1,3 +1,5 @@ +# Architetture Software + ## Una doverosa premessa Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. From 27a675f2e422d5a53b78139d406a18bccb4a4185 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 3 Nov 2023 17:01:07 +0100 Subject: [PATCH 48/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 876d7a44..1b637cf7 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -52,9 +52,9 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Conoscenza del business**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. - **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. -## Ma quindi chi si occupa di architetture software deve essere necessariamente senior? +## Chi si occupa di architettura software -No, non necessariamente. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. +Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. ## Misurare la bontà di un'architettura From cfc243aeae7ee02b505e26d58b9957c2661419fe Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 3 Nov 2023 17:01:21 +0100 Subject: [PATCH 49/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 1b637cf7..7cf1bd52 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -117,7 +117,7 @@ Ad ogni architettura software è associato un elenco contenente i punti chiave c Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. -I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore logicamente migliore per il punto chiave in questione, mentre per _basso_ si intende il valore logicamente peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. +I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. ### Monolite From 929f057e8bb9aeadd77fa2bcfa854f3ed63857fe Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 3 Nov 2023 17:06:33 +0100 Subject: [PATCH 50/75] Update docs/architetture-software/README.md Co-authored-by: Tommaso Allevi --- docs/architetture-software/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architetture-software/README.md b/docs/architetture-software/README.md index 7cf1bd52..2f431cbb 100644 --- a/docs/architetture-software/README.md +++ b/docs/architetture-software/README.md @@ -140,7 +140,7 @@ In questa architettura il database, il back-end e il front-end sono tutti parte Il monolite modulare è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto, ma con la differenza che il codice è organizzato in moduli. Questi moduli possono essere sviluppati e distribuiti in maniera indipendente, ma sono comunque parte dello stesso _blocco_, inteso che l'applicativo online è unico, come nel caso del monolite _classico_. -I moduli devono essere quanto possibile indipendenti tra di loro, il che affianca questa tipologia al concetto di _architettura esagonale_, tanto che a volte i due termini vengono usati indistintamente per intendere lo stesso concetto. La forza di questa architettura è comunque la possibilità, seppur da tenere sotto controllo, di far comunicare tra di loro i moduli. +I moduli devono essere quanto possibile indipendenti tra di loro in modo da avere una suddivisione delle funzionalità segregata. La forza di questa architettura è comunque la possibilità, seppur da tenere sotto controllo, di far comunicare tra di loro i moduli tramite delle interfacce pubbliche. Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. From 200a6d2d74c6db25ff20b938d647fcb679beb41e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 3 Nov 2023 17:30:52 +0100 Subject: [PATCH 51/75] chore: file rename --- .../README.md => it/architetture-software.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/{architetture-software/README.md => it/architetture-software.md} (100%) diff --git a/docs/architetture-software/README.md b/docs/it/architetture-software.md similarity index 100% rename from docs/architetture-software/README.md rename to docs/it/architetture-software.md From 5eed72ef146abcfa86c371b78486441d68f0a17a Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:50:03 +0100 Subject: [PATCH 52/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 2f431cbb..32ddcc55 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -14,7 +14,7 @@ Wikipedia ci dà uno spunto di partenza: > L'architettura software è l'insieme delle strutture necessarie per ragionare su un sistema software e la disciplina per creare tali strutture e sistemi. Ogni struttura comprende elementi software, relazioni tra loro e proprietà di entrambi gli elementi e delle relazioni. -In parole povere, l'architettura software è l'insieme di tutte le decisioni prese durante la progettazione di un sistema software. +In altre parole, l'architettura software è l'insieme di tutte le decisioni prese durante la progettazione di un sistema software. ## Il contesto aziendale From bca53c2e117aff1cbdf91abdd7e1a52430c04493 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:50:29 +0100 Subject: [PATCH 53/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 32ddcc55..97fb53e0 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -18,7 +18,7 @@ In altre parole, l'architettura software è l'insieme di tutte le decisioni pres ## Il contesto aziendale -Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova, in quanto, uno sviluppo/progetto si inserisce in un contesto aziendale che deve essere tenuto in conto per una più facile integrazione. +Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto si inserisce in un contesto aziendale che deve essere tenuto in conto in fase di progettazione per rendere l'implementazione più semplice. L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. From 0a0b8e5990d6b800ddc3cd4e0da4900c5409a429 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:52:01 +0100 Subject: [PATCH 54/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 97fb53e0..45b8725b 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -22,7 +22,7 @@ Chi si occupa di architetture software non può vivere in una bolla e non può e L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. -Inoltre, l'architettura del software può influenzare la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura di agilità e reattività, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. +Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura di agilità e reattività, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettato tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. From 4519af7b66fc2d1409bf71ce978a7f9520043edb Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:53:13 +0100 Subject: [PATCH 55/75] Update docs/it/architetture-software.md --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 45b8725b..63da5e10 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -24,7 +24,7 @@ L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli as Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura di agilità e reattività, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. -In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettato tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. +In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. ## I diversi aspetti dell'architettura software From 5d7a8d919fbf36b1a612d1483531893567104921 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:53:50 +0100 Subject: [PATCH 56/75] Update docs/it/architetture-software.md --- docs/it/architetture-software.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 63da5e10..6a1480bc 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -52,7 +52,6 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Conoscenza del business**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. - **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. -## Chi si occupa di architettura software Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. From a6b108930efa1218c90427b19798647a59f235d5 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 17:54:30 +0100 Subject: [PATCH 57/75] Update docs/it/architetture-software.md --- docs/it/architetture-software.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 6a1480bc..7f915639 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -1,7 +1,5 @@ # Architetture Software -## Una doverosa premessa - Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. From aa6737e648061bd3ca312945d75f9393d19b8626 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 18:37:37 +0100 Subject: [PATCH 58/75] chore: linting --- docs/it/architetture-software.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 7f915639..ceec4034 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -50,7 +50,6 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Conoscenza del business**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. - **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. - Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. ## Misurare la bontà di un'architettura From ecc7060ac7fb41c4ee86ddb12f5ae1f91d495073 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 13 Nov 2023 17:13:30 +0100 Subject: [PATCH 59/75] Update docs/it/architetture-software.md Co-authored-by: Angelo Cassano --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index ceec4034..4fe46bcc 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -1,6 +1,6 @@ # Architetture Software -Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione di architettura software e di descriverne le principali. +Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione e di descriverne le principali. Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. From a0a66348152e365da9b8aa650c32e5e8d4d6429a Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 13 Nov 2023 17:13:56 +0100 Subject: [PATCH 60/75] Update docs/it/architetture-software.md Co-authored-by: Angelo Cassano --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 4fe46bcc..55d21784 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -20,7 +20,7 @@ Chi si occupa di architetture software non può vivere in una bolla e non può e L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. -Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura di agilità e reattività, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. +Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. From 23035798ddb475d5023bd01aa0937be1184dfd75 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 13 Nov 2023 17:14:30 +0100 Subject: [PATCH 61/75] Update docs/it/architetture-software.md Co-authored-by: Angelo Cassano --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 55d21784..d0789bce 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -22,7 +22,7 @@ L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli as Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. -In sintesi, l'architettura software non è solo un dettaglio tecnico ma un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e dell'allineamento con gli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. +In sintesi, l'architettura software non rappresenta solo un aspetto tecnico ma è un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e in funzione degli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. ## I diversi aspetti dell'architettura software From 2fa4c15b9029836ee7d549c835a64b57ae5a162d Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 13 Nov 2023 17:17:17 +0100 Subject: [PATCH 62/75] Update docs/it/architetture-software.md Co-authored-by: Angelo Cassano --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index d0789bce..7349f7a9 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -16,7 +16,7 @@ In altre parole, l'architettura software è l'insieme di tutte le decisioni pres ## Il contesto aziendale -Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto si inserisce in un contesto aziendale che deve essere tenuto in conto in fase di progettazione per rendere l'implementazione più semplice. +Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto va contestualizzato tenendo conto di queste caratteristiche durante la fase di progettazione per rendere l'implementazione più semplice. L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. From 92700d456ffb7d1199c460389e176b2756bc478c Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 15 Nov 2023 10:54:26 +0100 Subject: [PATCH 63/75] Update docs/it/architetture-software.md Co-authored-by: Corrado Petrelli --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 7349f7a9..7016dee0 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -56,7 +56,7 @@ Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienz Il termine _fitness function_ viene spesso adottato quando si parla di architetture evolutive, ovvero architetture software il cui scopo è quello di evolvere nel tempo, adattandosi ai cambiamenti del business e del mercato. Possono essere assimilabili a delle metriche che permettono di valutare quanto un'architettura software sia adatta a raggiungere gli obiettivi prefissati o ad eventuali obiettivi futuri del business. -Apiumhub nel 2020 ha pubblicato un post sul proprio blog in cui definisce questo concetto in maniera molto chiara: +Apiumhub nel 2020 ha pubblicato un [post](https://apiumhub.com/tech-blog-barcelona/architectural-fitness-function) sul proprio blog in cui definisce questo concetto in maniera molto chiara: > La _fitness functions_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. From 937e3c34e251dc6d3cc5f22fb0bea09327f09770 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 16 Nov 2023 14:55:07 +0100 Subject: [PATCH 64/75] chore: aggiunta tabella --- docs/it/architetture-software.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 7016dee0..a5308379 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -115,6 +115,17 @@ Questi punti chiave sono da intendersi come una valutazione soggettiva, in quant I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. +Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni architettura. + +| | **Monolite** | **Monolite modulare** | **Microkernel** | **Microservizi** | **Service-based** | +|-----------------------------|--------------|-----------------------|-----------------|------------------|-------------------| +| **Start-up** | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | +| **Costi** | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Sviluppo e manutenzione** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | +| **Tracciabilità** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Scalabilità** | ⭐️ | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Performance** | ⭐️⭐️ | ⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | + ### Monolite Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, in quanto questi ultimi risiedono all'interno dello stesso processo. From 210ea8c49a6dbd297a0fe6c731ff40787a983261 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 16 Nov 2023 14:55:20 +0100 Subject: [PATCH 65/75] chore: lint --- docs/it/architetture-software.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index a5308379..04f635de 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -117,14 +117,14 @@ I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni architettura. -| | **Monolite** | **Monolite modulare** | **Microkernel** | **Microservizi** | **Service-based** | -|-----------------------------|--------------|-----------------------|-----------------|------------------|-------------------| -| **Start-up** | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | -| **Costi** | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | -| **Sviluppo e manutenzione** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | -| **Tracciabilità** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | -| **Scalabilità** | ⭐️ | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | -| **Performance** | ⭐️⭐️ | ⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| | **Monolite** | **Monolite modulare** | **Microkernel** | **Microservizi** | **Service-based** | +| --------------------------- | --------------- | --------------------- | --------------- | ---------------- | ----------------- | +| **Start-up** | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | +| **Costi** | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Sviluppo e manutenzione** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | +| **Tracciabilità** | ⭐️⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Scalabilità** | ⭐️ | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +| **Performance** | ⭐️⭐️ | ⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ### Monolite From d4bb2c3f6af9d191e52bd42943cdfacc026e2251 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 5 Dec 2023 17:06:36 +0100 Subject: [PATCH 66/75] chore: Code Review Co-authored-by: Paolo Martinoli <81316809+ugho16@users.noreply.github.com> --- docs/it/architetture-software.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 04f635de..f32b3758 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -31,10 +31,10 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide - **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. - **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. - **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui vengono gestiti gli errori, ripristinati i guasti e organizzati gli adattamenti per far fronte all'aumento del carico. -- **Attributi di qualità**: soddisfano i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Gli architetti prendono decisioni di progettazione per ottimizzare il software in funzione di queste qualità. -- **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Gli architetti sfruttano i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli ottenendo al tempo stesso la funzionalità desiderata. +- **Attributi di qualità**: soddisfano i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Le decisioni di progettazione per ottimizzare il software vengono prese in funzione di queste qualità. +- **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Chi si occupa dell'architettura sfrutta i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli, ottenendo al tempo stesso la funzionalità desiderata. -In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta gli sviluppatori a prendere decisioni informate e a creare software che resistano alla prova del tempo. +In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta chi sviluppa a prendere decisioni informate e a creare software che resistano alla prova del tempo. ## Chi si occupa di architetture software? @@ -128,7 +128,7 @@ Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni archit ### Monolite -Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, in quanto questi ultimi risiedono all'interno dello stesso processo. +Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, dal momento che questi ultimi risiedono all'interno dello stesso processo. Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. @@ -171,7 +171,7 @@ In questa architettura il database, il back-end e il front-end sono tutti parte - **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere più tempo. - **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. -- **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sul quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. +- **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sulla quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. - **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è mediamente complesso. L'isolamento dei plugin aiuta con il testing, ma la correlazione col nucleo centrale a volte può rallentare il processo di tracciamento. - **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, che non ne permette la _scalabilità orizzontale_. - **Performance**: 4. Processi di comunicazione semplici e isolabilità rendono questa architettura molto performante. From db78795db71006c48df30ca8c95af418e245e5ac Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 5 Dec 2023 17:10:29 +0100 Subject: [PATCH 67/75] chore: aggiunta nota scalabilita --- docs/it/architetture-software.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index f32b3758..91c04555 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -111,6 +111,10 @@ Ad ogni architettura software è associato un elenco contenente i punti chiave c - **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, quanto dell'impegno tecnico necessario per scalare il software. - **Performance**: La velocità con la quale il software è in grado di elaborare i dati per rispondere ad un'esigenza di business. +Quando parliamo di _scalabilità verticale_ ci riferiamo all'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. + +Quando parliamo di _scalabilità orizzontale_ ci riferiamo alla replicazione dei componenti del sistema, in modo da poter gestire un carico di lavoro maggiore. Le tecniche di scalabilità orizzontale sono varie e possono essere implementate in modi diversi, in base alle esigenze del sistema. + Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. From 724477ecf6a739405f5224c1b76199ef17fb00fc Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 22 Dec 2023 15:30:51 +0100 Subject: [PATCH 68/75] chore: rivisti alcuni contenuti in base alle review di allevo e serenasensini --- docs/it/architetture-software.md | 95 +++++++++++++++++--------------- 1 file changed, 50 insertions(+), 45 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 91c04555..1a172e64 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -14,16 +14,6 @@ Wikipedia ci dà uno spunto di partenza: In altre parole, l'architettura software è l'insieme di tutte le decisioni prese durante la progettazione di un sistema software. -## Il contesto aziendale - -Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto va contestualizzato tenendo conto di queste caratteristiche durante la fase di progettazione per rendere l'implementazione più semplice. - -L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. - -Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. - -In sintesi, l'architettura software non rappresenta solo un aspetto tecnico ma è un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e in funzione degli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. - ## I diversi aspetti dell'architettura software L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che si applicano nella maggior parte dei casi: @@ -36,6 +26,16 @@ L'architettura software è un argomento molto vasto e complesso, ma possiamo ide In sostanza, l'architettura software fornisce un approccio strutturato alla costruzione di sistemi software complessi, garantendo che siano scalabili, manutenibili e in grado di soddisfare i requisiti e gli standard di qualità previsti. È una disciplina cruciale nell'ingegneria del software che aiuta chi sviluppa a prendere decisioni informate e a creare software che resistano alla prova del tempo. +## Il contesto aziendale + +Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto va contestualizzato tenendo conto di queste caratteristiche durante la fase di progettazione per rendere l'implementazione più semplice. + +L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. + +Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. + +In sintesi, l'architettura software non rappresenta solo un aspetto tecnico ma è un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e in funzione degli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. + ## Chi si occupa di architetture software? Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo in base ai vincoli prestabiliti. @@ -44,10 +44,10 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Competenza tecnica**: questa figura dovrebbe avere una profonda conoscenza di vari linguaggi di programmazione, metodologie di sviluppo software e modelli architetturali. Deve rimanere aggiornata con le tecnologie emergenti e le tendenze nell'ingegneria del software. Seppure ci siano varie opinioni sulla necessità di conoscere più di un linguaggio di programmazione, è indubbio che conoscerne più di uno possa aiutare a trovare soluzioni più efficaci in modo particolare se aiuta la comprensione dei limiti che i vari contesti pongono. - **Attitudine al problem-solving**: sono essenziali forti capacità analitiche e di risoluzione dei problemi. Questa figura deve analizzare problemi complessi, identificare soluzioni e prendere decisioni che incidono sulla progettazione complessiva del sistema. -- **Comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. +- **Capacità di comunicazione**: una comunicazione efficace è fondamentale poiché le persone che ricoprono questo ruolo devono collaborare con team interfunzionali, parti interessate e con il team di sviluppo. Devono articolare la propria visione, le scelte progettuali e i concetti tecnici alle parti interessate non tecniche, facendo da ponte tra i due mondi. - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. -- **Conoscenza del business**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. +- **Business thinking**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. - **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. @@ -58,25 +58,27 @@ Il termine _fitness function_ viene spesso adottato quando si parla di architett Apiumhub nel 2020 ha pubblicato un [post](https://apiumhub.com/tech-blog-barcelona/architectural-fitness-function) sul proprio blog in cui definisce questo concetto in maniera molto chiara: -> La _fitness functions_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. +> La _fitness function_ è un tipo di funzione obiettivo utilizzata per riassumere quanto una determinata soluzione di architettura software sia vicina al raggiungimento degli obiettivi prefissati. Nel definire un'architettura evolutiva, l'architetto del software cerca un algoritmo "migliore"; la funzione fitness definisce cosa significa "migliore" in questo contesto. Esempi di fitness function possono essere: punteggio di scalabilità, percentuale di errori, tempo medio di risposta, quantità di messaggi persi dal broker, ecc. -### Triggered Fitness functions +Poiché gli obiettivi prefissati di un'architettura variano da progetto a progetto, non esiste una _fitness function_ che è possibile usare ovunque. Di seguito diamo alcune idee di implementazione. -Le _triggered fitness functions_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazioni o una persona del QA che esegue determinate attività stabilite. +### Triggered Fitness function + +Le _triggered fitness function_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazioni o una persona del QA che esegue determinate attività stabilite. Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentativo di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. Queste funzioni di fitness vengono spesso lanciate durante una _pipeline_ di distribuzione, in modo da intercettare eventuali variazioni prima che il software venga rilasciato in produzione. -Questo tipo di _fitness function_ richiede solitamente più manutenzione rispetto alle _continuous fitness functions_, poiché deve essere adattato durante la vita del software, in base alle modifiche che vengono apportate. +Questo tipo di _fitness function_ richiede solitamente più manutenzione rispetto alle _continuous fitness function_, poiché deve essere adattato durante la vita del software, in base alle modifiche che vengono apportate. Alcuni esempi sono i test unitari, i test di integrazione, ecc. -### Continuous Fitness functions +### Continuous Fitness function -Le _continuous fitness functions_ (funzioni di fitness _continue_) vengono eseguite in modo continuo sull'ambiente in analisi, tramite raccolta di metriche in tempo reale o comunque a cadenze rapide. Questo tipo di funzioni di fitness sono utili per monitorare il sistema e rilevare eventuali problemi prima che si verifichino, o analizzare dei trend. +Le _continuous fitness function_ (funzioni di fitness _continue_) vengono eseguite in modo continuo sull'ambiente in analisi, tramite raccolta di metriche in tempo reale o comunque a cadenze rapide. Questo tipo di funzioni di fitness sono utili per monitorare il sistema e rilevare eventuali problemi prima che si verifichino, o analizzare dei trend. Questo tipo di funzioni ha da un lato il vantaggio di rappresentare la situazione reale, dall'altro lato ha il difetto di non essere replicabile, in quanto si basa su dati presi dall'ambiente che si sta analizzando (solitamente quello di produzione). @@ -84,20 +86,6 @@ Queste funzioni di fitness vengono spesso lanciate in un ambiente di produzione, Alcuni esempi sono il monitoraggio dei tempi medi di risposta, il monitoraggio dei messaggi inviati e ricevuti in una coda, ecc. -## Architecture Decision Records - -Gli _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. - -A differenza di una classica documentazione tecnica o di un diagramma, le ADR sono molto più semplici da scrivere e da leggere, in quanto sono composte da pochi elementi: - -- **Titolo**: il titolo della decisione presa. -- **Stato**: lo stato della decisione presa. Solitamente può essere _Proposta_, _Accettata_, _Completata_, _Rifiutata_ o _Sostituita_. -- **Contesto**: il contesto in cui è stata presa la decisione. -- **Decisione**: la decisione presa. -- **Conseguenze**: le conseguenze della decisione presa. - -Le ADR vengono spesso utilizzate nelle aziende in cui si fa leva sul _BDD_ (Behavior Driven Development) per la stesura dei ticket nel proprio sistema di ticketing, puntando ad uno specifico ADR per dare informazioni aggiuntive e contesto a chi legge il ticket. - ## Quali sono le principali architetture software? Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. Quanto segue è un elenco non esaustivo delle principali architetture software, diventato però nel corso dei decenni uno standard de facto. @@ -105,17 +93,18 @@ Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. Q Ad ogni architettura software è associato un elenco contenente i punti chiave che seguono: - **Start-up**: Il tempo necessario per definire l'architettura software e cominciare a sviluppare funzionalità. Tale tempo non è da sottovalutare poiché potrebbe richiede, in base al contesto aziendale, una serie di procedure che possono essere automatizzate da tools come le `platform engineering tools`. -- **Costi**: Il costo che si affronta nell'arco della vita di un progetto o un prodotto che implementi questa architettura. +- **Costi**: Il costo che si affronta nell'arco della vita di un progetto o un prodotto che implementi questa architettura. Da considerare che nell'effettiva valutazione dei costi bisogna differenziare eventuali costi di avvio, da pagare una tantum, da costi ricorrenti, da pagare periodicamente per la manutenzione. - **Sviluppo e manutenzione**: La facilità con il quale è possibile effettuare modifiche e manutenzione al software. Per semplicità, anche l'aspetto del testing viene incluso in questo punto. - **Tracciabilità**: La facilità con la quale è possibile individuare problemi o bug all'interno del software. -- **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, quanto dell'impegno tecnico necessario per scalare il software. +- **Scalabilità**: La facilità con la quale è possibile scalare il software, ovvero la capacità di gestire un carico di lavoro maggiore. Questo punto non fa riferimento alla scalabilità orizzontale o a quella verticale e non tiene conto dei costi, ma dell'impegno tecnico necessario per scalare il software. - **Performance**: La velocità con la quale il software è in grado di elaborare i dati per rispondere ad un'esigenza di business. +Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. + Quando parliamo di _scalabilità verticale_ ci riferiamo all'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. Quando parliamo di _scalabilità orizzontale_ ci riferiamo alla replicazione dei componenti del sistema, in modo da poter gestire un carico di lavoro maggiore. Le tecniche di scalabilità orizzontale sono varie e possono essere implementate in modi diversi, in base alle esigenze del sistema. -Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. @@ -134,17 +123,17 @@ Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni archit Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, dal momento che questi ultimi risiedono all'interno dello stesso processo. -Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. +Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_. Solitamente questa architettura viene identificata anche come _Layered Architecture_. In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. - **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Fra i principali framework troviamo Ruby on Rails, Django, Spring Boot, Laravel, ecc. -- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplici da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. - **Tracciabilità**: 4. Poiché tutti i componenti fanno parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. -- **Scalabilità**: 1. Il monolite è tra le architetture software più difficili da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Scalabilità**: 1. Il monolite è tra le architetture software più difficili da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza, la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur buone nelle prime fasi di vita del software, tendono a degradare nel tempo. ### Monolite Modulare @@ -158,10 +147,10 @@ Da non confondersi con altre architetture, in questo caso i moduli sono parte de In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. - **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. -- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 5. Rispetto a un monolite _classico_, il monolite modulare è più semplice da sviluppare e mantenere, in quanto i moduli hanno un compito ben definito e sono quanto più possibile indipendenti tra di loro. - **Tracciabilità**: 2. Compattando i moduli in un unico blocco, è più difficile individuare la porzione di codice che ha generato un problema o un bug in quanto solitamente il codice dei singoli moduli viene minificato o comunque ottimizzato per la produzione. -- **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_, ovvero l'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. +- **Scalabilità**: 1. Il monolite, anche in forma modulare, è l'architettura software più difficile da scalare, in quanto non è possibile scalare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. - **Performance**: 1. La performance del monolite modulare presenta le stesse problematiche del monolite _classico_, con l'aggiunta che per far funzionare questa architettura è necessario un ulteriore livello di astrazione, ovvero il modulo, che può portare ad un degrado delle performance. ## Microkernel @@ -171,13 +160,13 @@ Questi plugin possono essere sviluppati e distribuiti in maniera indipendente, m Il concetto principale attorno a questa architettura è l'indipendenza totale tra i plugin. Per definizione, nessun plugin dovrebbe avere come dipendenza un altro plugin. -In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. +In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso applicativo. - **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere più tempo. -- **Costi**: 3. Pur essendo un'architettura _a costo zero_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. +- **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Trattasi di un'architettura semplice da mantenere e sulla quale aggiungere funzionalità, ma la necessità di non far comunicare i plugin tra di loro può aggiungere una lieve complessità. - **Tracciabilità**: 3. Testare e tracciare eventuali bug in questa architettura è mediamente complesso. L'isolamento dei plugin aiuta con il testing, ma la correlazione col nucleo centrale a volte può rallentare il processo di tracciamento. -- **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, che non ne permette la _scalabilità orizzontale_. +- **Scalabilità**: 2. Le difficoltà di scalabilità sono anche in questo caso dovute alla _singola unità di rilascio_ o _single deployment unit_, ovvero trattandosi di un unico applicativo, è necessario scalare l'intero sistema, dovendo quindi ricorrere alla _scalabilità verticale_. - **Performance**: 4. Processi di comunicazione semplici e isolabilità rendono questa architettura molto performante. ## Microservizi @@ -186,7 +175,7 @@ La _buzzword_ per eccellenza degli ultimi anni. Spesso affiancata alle architetture orientate agli eventi, questa architettura software si compone di un insieme di servizi indipendenti tra di loro, ognuno con un compito ben definito, che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. -A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli servizi, in quanto ogni servizio viene rilasciato in maniera indipendente. +A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli componenti, in quanto ogni componente è un applicativo separato (servizio) e viene rilasciato in maniera indipendente. In questa architettura ogni microservizio solitamente ha il proprio database e il proprio back-end (basato su API), mentre il front-end è solitamente un'interfaccia grafica che comunica con i microservizi attraverso le API, a prescindere da dove risieda o da come sia implementato. I database sono solitamente piccoli e si occupano di gestire solo i dati necessari al microservizio in questione. @@ -228,6 +217,22 @@ Una nota importante riguarda la _cell-based architecture_ che si pone come punto Altri termini, come la _event-driven architecture_ o la _event-sourcing architecture_ in realtà spesso si riferiscono ad un pattern di progettazione, ovvero un modo di progettare un sistema software, e non un'architettura software a tutti gli effetti. Il concetto di _event-driven_ viene infatti _affiancato_ più che _sostituito_ ad un'architettura software, come nel caso dei microservizi o del _service-based_. +## Documentazione + +### Architecture Decision Records + +Gli _Architecture Decision Records_ (ADR) sono un modo per documentare le decisioni prese durante la progettazione di un sistema software. Questo tipo di documentazione è molto utile per capire il perché di determinate scelte e per capire come il sistema è stato progettato. + +A differenza di una classica documentazione tecnica o di un diagramma, le ADR sono molto più semplici da scrivere e da leggere, in quanto sono composte da pochi elementi: + +- **Titolo**: il titolo della decisione presa. +- **Stato**: lo stato della decisione presa. Solitamente può essere _Proposta_, _Accettata_, _Completata_, _Rifiutata_ o _Sostituita_. +- **Contesto**: il contesto in cui è stata presa la decisione. +- **Decisione**: la decisione presa. +- **Conseguenze**: le conseguenze della decisione presa. + +Le ADR vengono spesso utilizzate nelle aziende in cui si fa leva sul _BDD_ (Behavior Driven Development) per la stesura dei ticket nel proprio sistema di ticketing, puntando ad uno specifico ADR per dare informazioni aggiuntive e contesto a chi legge il ticket. + ## Conclusioni L'architettura software è un argomento molto vasto e complesso, materia che ognuno di noi dovrebbe conoscere e comprendere, in quanto influenza ogni aspetto dello sviluppo software. @@ -238,4 +243,4 @@ D'altro canto, si consiglia a chiunque legga questi contenuti di non basarsi sul ## Riferimenti -La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da Mark Richards, autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme, tra cui O'Reilly e YouTube. +La lista di architetture software è ispirata e rivisitata a partire dal materiale prodotto e distribuito da [Mark Richards](https://www.developertoarchitect.com/), autore di molti libri sull'architettura software, video e webinar pubblicati su varie piattaforme, tra cui O'Reilly e YouTube. From 7ff85972d4504f82d710e38dcfa0c09f06b407eb Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 22 Dec 2023 15:31:07 +0100 Subject: [PATCH 69/75] chore: linting --- docs/it/architetture-software.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 1a172e64..7892e834 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -105,7 +105,6 @@ Quando parliamo di _scalabilità verticale_ ci riferiamo all'incremento delle ri Quando parliamo di _scalabilità orizzontale_ ci riferiamo alla replicazione dei componenti del sistema, in modo da poter gestire un carico di lavoro maggiore. Le tecniche di scalabilità orizzontale sono varie e possono essere implementate in modi diversi, in base alle esigenze del sistema. - I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni architettura. From 9c386724fe8da7c8f6b10e176b023195688d2367 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 23 Dec 2023 14:05:16 +0100 Subject: [PATCH 70/75] feat: rivisitazione di alcune parti del capitolo applicando suggerimenti di allevo --- docs/it/architetture-software.md | 34 +++++++++++++++++++------------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 7892e834..5070e75a 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -48,9 +48,9 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. - **Business thinking**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. -- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario. +- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario, non solo per necessità tecniche, ma anche per rispondere ai cambiamenti del mercato e per soddisfare le esigenze dei clienti. -Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di affiancare sempre una figura senior che possa guidare e supportare la persona junior. +Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di iniziare in un contesto controllato, più piccolo in modo da poter sperimentare meglio. L'affiancamento di una figura senior che possa guidare è sicuramente di aiuto per una persona junior. ## Misurare la bontà di un'architettura @@ -88,9 +88,9 @@ Alcuni esempi sono il monitoraggio dei tempi medi di risposta, il monitoraggio d ## Quali sono le principali architetture software? -Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. Quanto segue è un elenco non esaustivo delle principali architetture software, diventato però nel corso dei decenni uno standard de facto. +Esistono diverse architetture software, ognuna con i suoi pro e i suoi contro. In questa parte del libro, descriviamo le principali architetture software che, nel corso dei decenni, sono diventate uno standard de facto grazie alle loro molteplici implementazioni e casi di successo. -Ad ogni architettura software è associato un elenco contenente i punti chiave che seguono: +Per scegliere quale architettura usare in diversi contesti, possiamo fare riferimenti alle seguenti caratteristiche: - **Start-up**: Il tempo necessario per definire l'architettura software e cominciare a sviluppare funzionalità. Tale tempo non è da sottovalutare poiché potrebbe richiede, in base al contesto aziendale, una serie di procedure che possono essere automatizzate da tools come le `platform engineering tools`. - **Costi**: Il costo che si affronta nell'arco della vita di un progetto o un prodotto che implementi questa architettura. Da considerare che nell'effettiva valutazione dei costi bisogna differenziare eventuali costi di avvio, da pagare una tantum, da costi ricorrenti, da pagare periodicamente per la manutenzione. @@ -101,10 +101,6 @@ Ad ogni architettura software è associato un elenco contenente i punti chiave c Questi punti chiave sono da intendersi come una valutazione soggettiva, in quanto ogni architettura software può essere implementata in modi diversi, con conseguenze diverse, valutando criteri e parametri differenti in base alle proprie necessità e, pur essendo un elenco piuttosto esaustivo, mix di queste architetture hanno dimostrato di essere vincenti in molti casi, anche a discapito di quanto riportato qui sopra. -Quando parliamo di _scalabilità verticale_ ci riferiamo all'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. - -Quando parliamo di _scalabilità orizzontale_ ci riferiamo alla replicazione dei componenti del sistema, in modo da poter gestire un carico di lavoro maggiore. Le tecniche di scalabilità orizzontale sono varie e possono essere implementate in modi diversi, in base alle esigenze del sistema. - I punti chiave sono espressi con dei voti che vanno da 1 a 5, dove 1 è il voto più basso e 5 il voto più alto. Per _alto_ si intende il valore migliore per il punto chiave in questione, mentre per _basso_ si intende il valore peggiore per il punto chiave in questione, ovvero il valore che si vorrebbe evitare. Nel caso di _costi_, ad esempio, un voto alto significa che i costi sono bassi, mentre un voto basso significa che i costi sono alti. Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni architettura. @@ -118,22 +114,32 @@ Segue una tabella riepilogativa dei punti di forza e di debolezza di ogni archit | **Scalabilità** | ⭐️ | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | | **Performance** | ⭐️⭐️ | ⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️⭐️ | +Nelle sezioni che seguono verranno indicati alcuni termini che possono non essere familiari a tutti. Per questo motivo, quanto segue è un glossario dei termini più utilizzati. + +Quando parliamo di _scalabilità verticale_ ci riferiamo all'incremento delle risorse hardware a disposizione del sistema (CPU, RAM, storage, ecc.) quando queste non sono più sufficienti per gestire il carico di lavoro. + +Quando parliamo di _scalabilità orizzontale_ ci riferiamo alla replicazione dei componenti del sistema, in modo da poter gestire un carico di lavoro maggiore. Le tecniche di scalabilità orizzontale sono varie e possono essere implementate in modi diversi, in base alle esigenze del sistema. + +Quando parliamo di _layer applicativi_ ci riferiamo a un livello di astrazione del software. Il database, le API, il front-end, ecc. sono tutti layer del software. + ### Monolite -Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, dal momento che questi ultimi risiedono all'interno dello stesso processo. +Il monolite è un'architettura software in cui tutte le funzionalità sono sviluppate e distribuite come un singolo pacchetto. È il tipo di architettura più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti, dal momento che questi ultimi risiedono all'interno dello stesso applicativo. Trattasi dell'architettura software più semplice da implementare e più diffusa, ma anche la più difficile da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_. Solitamente questa architettura viene identificata anche come _Layered Architecture_. -In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. +In questa architettura i layer applicativi sono tutti parte dello stesso applicativo. + +È importante notare che storicamente questa architettura è spesso risultata la più sensibile al concetto di _stratificazione del codice_, ovvero il continuo sviluppo di funzionalità una sopra l'altra in sostituzione o sovrapposizione di precedenti, rendendo il codice sempre più complesso e difficile da mantenere. Questo fenomeno è stato spesso chiamato _Big Ball of Mud_. - **Start-up**: 5. Il monolite è l'architettura software più semplice da implementare, in quanto non richiede particolari accorgimenti per la comunicazione tra i vari componenti o una necessità di valutazioni iniziali elevate. Molti linguaggi di programmazione, inoltre, offrono dei framework che permettono di implementare un monolite in pochi minuti. Fra i principali framework troviamo Ruby on Rails, Django, Spring Boot, Laravel, ecc. - **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. - **Sviluppo e manutenzione**: 4. Il monolite è tra le architetture software più semplici da sviluppare e mantenere, per gli stessi motivi espressi nella voce _start-up_. I framework sono ormai molto maturi e permettono di sviluppare e mantenere un monolite in maniera molto semplice. - **Tracciabilità**: 4. Poiché tutti i componenti fanno parte dello stesso processo o blocco, è facile individuare la porzione di codice che ha generato un problema o un bug. - **Scalabilità**: 1. Il monolite è tra le architetture software più difficili da scalare, in quanto non è possibile replicare i singoli componenti, ma è necessario scalare l'intero sistema. In questi casi, infatti, al monolite viene affiancato il concetto di _scalabilità verticale_. La valutazione è dovuta alla necessità, nella maggior parte delle implementazioni di questo tipo, di dover riavviare il sistema per scalare le risorse hardware. -- **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza, la curva di crescita dei tempi di risposta tende ad essere esponenziale. Solitamente le performance, seppur buone nelle prime fasi di vita del software, tendono a degradare nel tempo. +- **Performance**: 2. La performance del monolite è legata alla capacità di scalare le risorse hardware a disposizione del sistema. Di conseguenza, la curva di crescita dei tempi di risposta tende a crescere sempre di più. Solitamente le performance, seppur buone nelle prime fasi di vita del software, tendono a degradare nel tempo. ### Monolite Modulare @@ -143,7 +149,7 @@ I moduli devono essere quanto possibile indipendenti tra di loro in modo da aver Da non confondersi con altre architetture, in questo caso i moduli sono parte dello stesso processo o applicativo, rendendo necessaria la _scalabilità verticale_. -In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso processo/applicativo. +In questa architettura i layer applicativi sono tutti parte dello stesso applicativo. - **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in moduli può richiedere un po' di tempo. - **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. @@ -159,7 +165,7 @@ Questi plugin possono essere sviluppati e distribuiti in maniera indipendente, m Il concetto principale attorno a questa architettura è l'indipendenza totale tra i plugin. Per definizione, nessun plugin dovrebbe avere come dipendenza un altro plugin. -In questa architettura il database, il back-end e il front-end sono tutti parte dello stesso applicativo. +In questa architettura i layer applicativi sono tutti parte dello stesso applicativo. - **Start-up**: 4. Essendo una variante del monolite, lo start-up è molto semplice, ma la necessità di organizzare il codice in un nucleo centrale e implementare un sistema di plugin può richiedere più tempo. - **Costi**: 3. Pur essendo un'architettura _a basso costo_ in termini di start-up, il costo cresce esponenzialmente per via della necessità di _scalare orizzontalmente_. @@ -172,7 +178,7 @@ In questa architettura il database, il back-end e il front-end sono tutti parte La _buzzword_ per eccellenza degli ultimi anni. -Spesso affiancata alle architetture orientate agli eventi, questa architettura software si compone di un insieme di servizi indipendenti tra di loro, ognuno con un compito ben definito, che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. +Questa architettura software si compone di un insieme di servizi indipendenti tra di loro, ognuno con un compito ben definito, che comunicano tra di loro attraverso un meccanismo di comunicazione _solitamente_ asincrono. A differenza delle architetture _a singolo blocco_ viste sopra, questa architettura permette di scalare i singoli componenti, in quanto ogni componente è un applicativo separato (servizio) e viene rilasciato in maniera indipendente. From c4e27d851b8f29e5ca12c5eb4f86f41e534f31e9 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sun, 24 Dec 2023 08:13:40 +0100 Subject: [PATCH 71/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 5070e75a..aa5a3bcf 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -2,7 +2,7 @@ Il termine "architettura software" viene spesso utilizzato in maniera molto generica e impropria. In questo documento cercheremo di dare una definizione e di descriverne le principali. -Inoltre, cercheremo di dare una definizione di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. +Inoltre, cercheremo di dare un'idea di "chi si occupa di architetture software" e di descrivere il suo ruolo all'interno di un team di sviluppo. L'argomento è molto vasto e complesso, per cui proveremo a dare una visione generale, senza entrare troppo nel dettaglio, in quanto ogni singola sezione di questo capitolo potrebbe concretizzarsi in un libro a sé stante. From e436107fa0e271a23810ec2957a0100c6ed03130 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sun, 24 Dec 2023 08:13:56 +0100 Subject: [PATCH 72/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index aa5a3bcf..07de1421 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -19,7 +19,7 @@ In altre parole, l'architettura software è l'insieme di tutte le decisioni pres L'architettura software è un argomento molto vasto e complesso, ma possiamo identificare alcuni punti chiave che si applicano nella maggior parte dei casi: - **Componenti e moduli**: identificano i principali componenti o moduli del software e descrivono le loro responsabilità. Questi componenti possono essere funzioni, classi o persino interi microservizi in un sistema distribuito. -- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione dei dati efficiente. +- **Flusso e comunicazione dei dati**: descrive il modo in cui i dati attraversano le diverse parti del sistema, inclusi meccanismi di input e output, database e servizi esterni. Comprendere il flusso di dati è fondamentale per garantire una comunicazione e un'elaborazione efficiente dei dati. - **Comportamento del sistema**: definisce il comportamento previsto del software in varie condizioni, incluso il modo in cui vengono gestiti gli errori, ripristinati i guasti e organizzati gli adattamenti per far fronte all'aumento del carico. - **Attributi di qualità**: soddisfano i requisiti non funzionali, come prestazioni, sicurezza, scalabilità e manutenibilità. Le decisioni di progettazione per ottimizzare il software vengono prese in funzione di queste qualità. - **Vincoli e modelli**: l'architettura software spesso opera entro determinati vincoli, come budget, stack tecnologico o standard di conformità. Chi si occupa dell'architettura sfrutta i modelli di progettazione e le migliori pratiche per soddisfare questi vincoli, ottenendo al tempo stesso la funzionalità desiderata. From 226165dbdb495b27a5a587ff432f9b6388e55b92 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sun, 24 Dec 2023 08:14:51 +0100 Subject: [PATCH 73/75] Apply suggestions from code review Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 07de1421..2f70688c 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -34,11 +34,11 @@ L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli as Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione. -In sintesi, l'architettura software non rappresenta solo un aspetto tecnico ma è un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando è progettata tenendo conto della collaborazione, della comunicazione e in funzione degli obiettivi aziendali, può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. +In sintesi, l'architettura software non rappresenta solo un aspetto tecnico ma è un potente strumento in grado di plasmare la cultura dell'organizzazione. Quando si progetta tenendo conto della collaborazione, della comunicazione e in funzione degli obiettivi aziendali, si può promuovere una cultura del lavoro di squadra, dell'adattabilità e dell'innovazione all'interno dell'organizzazione, contribuendo in definitiva al successo dei progetti di sviluppo software e dell'azienda nel suo insieme. ## Chi si occupa di architetture software? -Chi si occupa di architettura del software è di solito una persona con una certa seniority nel campo dell'ingegneria del software, responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo in base ai vincoli prestabiliti. +Chi si occupa di architettura del software è di solito una persona con una certa esperienza nel campo dell'ingegneria del software, ed è responsabile della progettazione e della supervisione della struttura di alto livello e della visione tecnica di un progetto o sistema software. Queste figure sono fondamentali per colmare il divario tra i requisiti concettuali di una soluzione software e la sua diretta implementazione. Il ruolo va oltre il codice: implica prendere decisioni strategiche sulla progettazione del sistema, garantire che sia in linea con gli obiettivi dell'organizzazione e ottimizzarlo in base ai vincoli prestabiliti. Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere: @@ -68,7 +68,7 @@ Poiché gli obiettivi prefissati di un'architettura variano da progetto a proget Le _triggered fitness function_ (funzioni di fitness _attivate_ o _triggerate_) vengono eseguite in base a un evento particolare, ad esempio il team di sviluppo che esegue un test unitario, una pipeline di distribuzione che esegue una serie di operazioni o una persona del QA che esegue determinate attività stabilite. -Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentativo di una situazione reale. Questo tipo di fitness function non tiene in considerazione, infatti, il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. +Questo tipo di funzioni ha da un lato il vantaggio di poter essere eseguito in maniera molto rapida, ma dall'altro lato ha il difetto di non essere rappresentativo di una situazione reale. Infatti, questo tipo di fitness function non tiene in considerazione il carico di lavoro che il sistema deve gestire durante il _day-by-day_, ma solo situazioni isolate e controllate. Queste funzioni di fitness vengono spesso lanciate durante una _pipeline_ di distribuzione, in modo da intercettare eventuali variazioni prima che il software venga rilasciato in produzione. From ae991780326275267bb4073c2adeadec351aaad5 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sun, 24 Dec 2023 08:15:45 +0100 Subject: [PATCH 74/75] Update docs/it/architetture-software.md --- docs/it/architetture-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 2f70688c..1d369d37 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -48,7 +48,7 @@ Di seguito le caratteristiche chiave che chi ricopre questo ruolo dovrebbe avere - **Leadership**: Queste figure spesso assumono ruoli di leadership, guidando i team di sviluppo, facendo da mentor a figure junior e garantendo che la visione architetturale venga seguita durante tutto il ciclo di vita del progetto. - **Design Thinking**: Le persone che ricoprono questo ruolo dovrebbero possedere una mentalità orientata al design, concentrandosi sulla creazione di soluzioni eleganti ed efficienti. Ciò include la progettazione per scalabilità, prestazioni, sicurezza ed esperienza utente. - **Business thinking**: comprendere il contesto di business aziendale e gli obiettivi che l'azienda si è posta di raggiungere. Queste figure devono allineare le loro decisioni tecniche con gli obiettivi strategici dell'organizzazione. -- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie, nonché capace di rivalutare e riadattare l'architettura quando necessario, non solo per necessità tecniche, ma anche per rispondere ai cambiamenti del mercato e per soddisfare le esigenze dei clienti. +- **Adattabilità**: il panorama del software è in continua evoluzione. La figura dovrebbe essere aperta e adattarsi a nuove tecnologie e metodologie e capace di rivalutare e riadattare l'architettura quando necessario, non solo per necessità tecniche, ma anche per rispondere ai cambiamenti del mercato e per soddisfare le esigenze dei clienti. Sebbene sia vero che il ruolo viene ricoperto da persone con una certa esperienza, non è detto che una figura junior non possa occuparsi di architetture software. Anzi, è molto importante che lo faccia, in quanto è un ottimo modo per imparare e crescere, ma il consiglio è di iniziare in un contesto controllato, più piccolo in modo da poter sperimentare meglio. L'affiancamento di una figura senior che possa guidare è sicuramente di aiuto per una persona junior. From adf30a892ed524a3f5ab2f74ae1030ee6fcd3e51 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 27 Dec 2023 10:00:58 +0100 Subject: [PATCH 75/75] Update docs/it/architetture-software.md Co-authored-by: Tommaso Allevi --- docs/it/architetture-software.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/it/architetture-software.md b/docs/it/architetture-software.md index 1d369d37..462c9876 100644 --- a/docs/it/architetture-software.md +++ b/docs/it/architetture-software.md @@ -30,6 +30,8 @@ In sostanza, l'architettura software fornisce un approccio strutturato alla cost Chi si occupa di architetture software non può vivere in una bolla e non può esulare dal contesto aziendale nel quale si trova: ogni progetto va contestualizzato tenendo conto di queste caratteristiche durante la fase di progettazione per rendere l'implementazione più semplice. +Essere quindi in grado di ascoltare e recepire le richieste e i cambiamenti del business e saper rispecchiare il tutto nel proprio lavoro quotidiano è fondamentale per prendere decisioni coerenti e creare architetture efficaci. + L'architettura software gioca un ruolo fondamentale nel plasmare non solo gli aspetti tecnici di un sistema software ma anche l'organizzazione e la cultura più ampia all'interno della quale viene sviluppato e mantenuto. Un'architettura software ben progettata può favorire una cultura organizzativa positiva in diversi modi. In primo luogo, può promuovere la collaborazione e la comunicazione tra i team di sviluppo fornendo un modello chiaro della struttura e dei componenti del sistema. Quando i membri del team hanno una comprensione condivisa dell'architettura, diventa più facile per loro lavorare insieme in modo efficace, allineare i propri sforzi e prendere decisioni informate, promuovendo una cultura del lavoro di squadra e della cooperazione. Inoltre, l'architettura del software può seguire la strategia e gli obiettivi generali dell'organizzazione. Un'architettura ben ponderata può garantire che il sistema software sia allineato con gli obiettivi aziendali, rendendo più facile per l'organizzazione adattarsi alle mutevoli condizioni del mercato e alle esigenze dei clienti. Questo allineamento tra software e obiettivi aziendali può aiutare a promuovere una cultura agile e reattiva, in cui l'organizzazione è più propensa ad abbracciare il cambiamento e l'innovazione.