book

Fundamentals of Software Architecture, 2a edizione

by Mark Richards, Neal Ford

March 2025

Intermediate to advanced

546 pages

16h 10m

Italian

O'Reilly Media, Inc.

Read now

Unlock full access

Prefazione alla seconda edizionePrefazione alla prima edizioneConvenzioni utilizzate in questo libroMateriale supplementareFormazione online O'ReillyCome contattarciRingraziamentiRingraziamenti di Mark RichardsRingraziamenti di Neal Ford
Definire l'architettura del softwareLe leggi dell'architettura del softwareAspettative di un architettoPrendere decisioni sull'architetturaAnalizzare continuamente l'architetturaTieniti aggiornato sulle ultime tendenzeGarantire la conformità alle decisioniComprendere le diverse tecnologieConoscere il dominio aziendalePossiede capacità interpersonaliCapire e navigare nella politicaMappa stradale
Architettura contro designDecisioni strategiche e tatticheLivello di impegnoL'importanza dei compromessiAmpiezza tecnicaLa regola dei 20 minutiSviluppare un radar personaleAnalizzare i compromessiComprendere i driver aziendaliBilanciare l'architettura e il codice praticoC'è di più nel pensiero architettonico
Modularità contro granularitàDefinire la modularitàMisurare la modularitàCoesioneAccoppiamentoMetriche fondamentaliDistanza dalla sequenza principaleConnascenzaDai moduli ai componenti
Caratteristiche architettoniche e design del sistemaCaratteristiche architettoniche (parzialmente) ElencateCaratteristiche architettoniche operativeCaratteristiche architettoniche strutturaliCaratteristiche di CloudCaratteristiche architettoniche trasversaliScambi e architettura del meno peggio
Estrarre le caratteristiche architettoniche dalle preoccupazioni del dominioCaratteristiche architettoniche compositeEstrazione delle caratteristiche architettonicheLavorare con KatasKata: Panini al silicioCaratteristiche espliciteCaratteristiche impliciteLimitare e dare priorità alle caratteristiche architettoniche
Misurare le caratteristiche dell'architetturaMisure operativeMisure strutturaliMisure di processoFunzioni di governance e fitnessCaratteristiche dell'architettura di governoFunzioni di fitness
Quante e granularità architettonicheComunicazione sincronaL'impatto dello scopingScoping e stile architettonicoKata: Go GreenScoping e Cloud
Definire i componenti logiciArchitettura logica e fisicaCreare un'architettura logicaIdentificare i componenti principaliAssegnare le Storie dell'Utente ai ComponentiAnalizzare ruoli e responsabilitàAnalizzare le caratteristiche architettonicheComponenti della ristrutturazioneAccoppiamento dei componentiAccoppiamento staticoAccoppiamento temporaleLa Legge di DemetraCaso di studio: Go, Go, Go: la scoperta dei componenti

Stili e modelliModelli fondamentaliUna grande palla di fangoArchitettura unitariaCliente/ServerPartizione dell'architetturaKata: Panini di silicio - PartizioneArchitetture monolite contro architetture distribuiteFallacia n. 1: la rete è affidabileFallacia #2: la latenza è zeroFallacia #3: La larghezza di banda è infinitaFallacia n. 4: la rete è sicuraFallacia #5: la topologia non cambia maiFallacia #6: c'è un solo amministratoreFallacia #7: il costo del trasporto è zeroFallacia n. 8: la rete è omogeneaLe altre fallacieTopologie e architetture di squadraPassiamo agli stili specifici
TopologiaSpecifiche dello stileStrati di isolamentoAggiunta di livelliTopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileQuando usarloQuando non usarloEsempi e casi d'uso
TopologiaSpecifiche dello stileStruttura monoliteStruttura modulareModulo ComunicazioneTopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileQuando usarloQuando non usarloEsempi e casi d'uso
TopologiaSpecifiche dello stileFiltriTubiTopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileQuando usarloQuando non usarloEsempi e casi d'uso
TopologiaSpecifiche dello stileSistema centraleComponenti plug-inLo spettro della "Microkern-alità"RegistroContrattiTopologie di datiConsiderazioni sul CloudRischi comuniNucleo volatileDipendenze dei plug-inLa governanceConsiderazioni sulla topologia del teamCaratteristiche dell'architettura ValutazioniEsempi e casi d'uso
TopologiaSpecifiche dello stileProgettazione e granularità del servizioOpzioni dell'interfaccia utenteOpzioni del gateway APITopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileEsempi e casi d'uso
TopologiaSpecifiche dello stileEventi contro messaggiEventi derivatiAttivazione di eventi estensibiliFunzionalità asincroneCapacità di trasmissioneCarico utile dell'eventoL'antipattern Sciame di mosceriniGestione degli erroriPrevenire la perdita di datiElaborazione di richieste e risposteArchitettura guidata dagli eventi mediataTopologie di datiTopologia di database monoliteTopologia del database di dominioTopologia dati dedicataConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileScelta tra modelli basati sulle richieste e modelli basati sugli eventiEsempi e casi d'uso
TopologiaSpecifiche dello stileUnità di elaborazioneMiddleware virtualizzatoGriglia di messaggisticaGriglia di datiGriglia di elaborazioneGestore della distribuzionePompe datiScrittori di datiLettori di datiTopologie di datiConsiderazioni sul CloudRischi comuniLetture frequenti dal databaseSincronizzazione e coerenza dei datiVolumi di dati elevatiCollisioni di datiLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileEsempi e casi d'usoSistema di biglietteria per concertiSistema di aste online
TopologiaSpecifiche dello stileTassonomiaRiutilizzo... e accoppiamentoTopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileEsempi e casi d'uso
TopologiaSpecifiche dello stileContesto delimitatoGranularitàIsolamento dei datiLivello APIRiutilizzo operativoFrontendComunicazioneCoreografia e orchestrazioneTransazioni e SagheTopologie di datiConsiderazioni sul CloudRischi comuniLa governanceConsiderazioni sulla topologia del teamCaratteristiche dello stileEsempi e casi d'uso
Il cambiamento della "moda" nell'architetturaCriteri decisionaliCaso di studio di monolite: Panini al silicioMonolite modulareMicrokernelCaso di studio distribuito: Go, Go, Go
RiutilizzoSeparare il dominio e l'accoppiamento operativoComunicazioneOrchestrazione contro coreografiaCQRSInfrastruttureModello Broker-Dominio
Antipattern delle decisioni architettonicheL'antipattern della copertura dei beniAntipattern del Giorno della MarmottaAntipattern dell'architettura guidata dalle e-mailSignificato architettonicoRegistri delle decisioni architettonicheStruttura di baseEsempioMemorizzazione degli ADRLe ADR come documentazioneUtilizzo degli ADR per gli standardUtilizzare gli ADR con i sistemi esistentiSfruttare l'intelligenza artificiale generativa e le LLM nelle decisioni architettoniche
Matrice di rischioValutazioni del rischioTempesta di rischiFase 1: IdentificazioneFase 2: consensoFase 3: Mitigazione del rischioAnalisi del rischio della storia dell'utenteCaso d'uso del Risk-StormingDisponibilitàElasticitàSicurezzaSommario
DiagrammazioniStrumentiGli standard di diagrammazione: UML, C4 e ArchiMateLinee guida per i diagrammiSommario
CollaborazioneVincoli e confiniPersonalità dell'architettoL'architetto maniaco del controlloL'architetto in poltronaL'architetto efficaceQuanto coinvolgimento?Segnali di allarme per la squadraPerdita di processoIgnoranza pluralisticaSfruttare le liste di controlloLista di controllo per lo sviluppo del codiceLista di controllo dei test unitari e funzionaliLista di controllo per il rilascio del softwareFornire una guidaSommario
Negoziazione e facilitazioneNegoziare con gli stakeholder aziendaliNegoziare con altri architettiNegoziare con gli sviluppatoriL'architetto del software come leaderLe 4 C dell'architetturaSii pragmatico, ma anche visionarioGuidare i team con l'esempioIntegrazione con il team di sviluppoRiassunto
Architettura e implementazioneProblemi operativiIntegrità strutturaleVincoli architettoniciArchitettura e infrastrutturaArchitettura e topologie di datiTopologia del databaseCaratteristiche architettonicheStruttura dei datiPriorità di lettura/scritturaPratiche di architettura e ingegneriaArchitettura e topologie di squadraArchitettura e integrazione dei sistemiArchitettura e impresaArchitettura e ambiente aziendaleArchitettura e IA generativaIncorporare l'intelligenza artificiale generativa nell'architetturaL'IA generativa come assistente architettoRiassunto
Prima legge: Nell'architettura del software tutto è un compromessoBiblioteca condivisa contro servizio condivisoMessaggistica sincrona contro quella asincronaPrimo corollario: Scomparsa dei compromessiSecondo corollario: Non puoi farlo solo una voltaSeconda Legge: Il perché è più importante del comeAntipattern fuori contestoLo spettro tra gli estremiParole di congedo e consigli
Capitolo 1: IntroduzioneCapitolo 2: Il pensiero architettonicoCapitolo 3: ModularitàCapitolo 4: Definizione delle caratteristiche dell'architetturaCapitolo 5: Identificazione delle caratteristiche architettonicheCapitolo 6: Misurare e governare le caratteristiche dell'architetturaCapitolo 7: L'ambito delle caratteristiche architettonicheCapitolo 8: Pensiero basato sui componentiCapitolo 9: FondazioniCapitolo 10: Stile di architettura a stratiCapitolo 11: Stile di architettura modulare monoliteCapitolo 12: Stile dell'architettura della pipelineCapitolo 13: Stile dell'architettura microkernelCapitolo 14: Stile di architettura basato sui serviziCapitolo 15: Stile dell'architettura guidata dagli eventiCapitolo 16: Stile architettonico basato sullo spazioCapitolo 17: Architettura orientata ai servizi guidata dall'orchestrazioneCapitolo 18: Architettura a microserviziCapitolo 19: Scegliere lo stile di architettura appropriatoCapitolo 20: Modelli architettoniciCapitolo 21: Decisioni architettonicheCapitolo 22: Analisi del rischio dell'architetturaCapitolo 23: Diagrammare l'architetturaCapitolo 24: Rendere efficaci i teamCapitolo 25: Abilità di negoziazione e leadershipCapitolo 26: Intersezioni architettonicheCapitolo 27: Le leggi dell'architettura del software, rivisitate

Content preview from Fundamentals of Software Architecture, 2a edizione

Parte III. Tecniche e competenze trasversali

Un architetto del software efficace non deve solo comprendere gli aspetti tecnici dell'architettura del software, ma anche le tecniche principali e le soft skills necessarie per pensare come un architetto, guidare i team di sviluppo e comunicare efficacemente l'architettura ai vari stakeholder. Questa sezione del libro affronta le tecniche principali e le competenze trasversali necessarie per diventare un architetto del software efficace.