Costruire architetture esagonali suAWS

Furkan Oruc, Dominik Goby, Darius Kunce e Michal Ploski, Amazon Web Services (AWS)

Giugno 2022 (cronologia dei documenti)

Questa guida descrive un modello mentale e una raccolta di modelli per lo sviluppo di architetture software. Queste architetture sono facili da mantenere, estendere e scalare all'interno dell'organizzazione man mano che l'adozione dei prodotti cresce. Gli hyperscaler cloud come Amazon Web Services (AWS) forniscono elementi costitutivi per le piccole e grandi imprese per innovare e creare nuovi prodotti software. Il ritmo rapido di queste nuove introduzioni di servizi e funzionalità induce gli stakeholder aziendali ad aspettarsi che i loro team di sviluppo realizzino prototipi più rapidamente di nuovi prodotti minimi viabili (MVP), in modo che le nuove idee possano essere testate e verificate il prima possibile. Spesso, questi MVP vengono adottati e diventano parte dell'ecosistema software aziendale. Nel processo di produzione di questi MVP, i team a volte abbandonano le regole e le migliori pratiche di sviluppo del software, come i principi SOLID e i test unitari. Presumono che questo approccio accelererà lo sviluppo e ridurrà i tempi di commercializzazione. Tuttavia, se non riescono a creare un modello di base e un framework per l'architettura del software a tutti i livelli, sarà difficile o addirittura impossibile sviluppare nuove funzionalità per il prodotto. La mancanza di certezze e il cambiamento dei requisiti possono anche rallentare il team durante il processo di sviluppo.

Questa guida illustra un'architettura software proposta, da un'architettura esagonale di basso livello a una scomposizione architettonica e organizzativa di alto livello, che utilizza la progettazione basata sul dominio (DDD) per affrontare queste sfide. DDD aiuta a gestire la complessità aziendale e a scalare il team di progettazione man mano che vengono sviluppate nuove funzionalità. Allinea gli stakeholder aziendali e tecnici ai problemi aziendali, chiamati domini, utilizzando un linguaggio onnipresente. L'architettura esagonale è un fattore tecnico di questo approccio in un dominio molto specifico, chiamato contesto limitato. Un contesto limitato è una sottoarea del problema aziendale altamente coesa e poco accoppiata. Ti consigliamo di adottare un'architettura esagonale per tutti i tuoi progetti software aziendali indipendentemente dalla loro complessità.

L'architettura esagonale incoraggia il team di progettazione a risolvere innanzitutto il problema aziendale, mentre l'architettura classica a strati sposta l'attenzione della progettazione dal dominio alla risoluzione dei problemi tecnici prima di tutto. Inoltre, se il software segue un'architettura esagonale, è più facile adottare un approccio di sviluppo basato sui test, che riduce il ciclo di feedback di cui gli sviluppatori hanno bisogno per testare i requisiti aziendali. Infine, l'uso di comandi e gestori di comandi è un modo per applicare i principi di responsabilità unica e aperta di SOLID. L'adesione a questi principi produce una base di codice che gli sviluppatori e gli architetti che lavorano al progetto possono facilmente navigare e comprendere e riduce il rischio di introdurre modifiche sostanziali alle funzionalità esistenti.

Questa guida è destinata agli architetti e agli sviluppatori di software interessati a comprendere i vantaggi dell'adozione dell'architettura esagonale e del DDD per i loro progetti di sviluppo software. Include un esempio di progettazione di un'infrastruttura per l'applicazioneAWS che supporti l'architettura esagonale. Per un esempio di implementazione, consulta Strutturare un progetto Python in architettura esagonale utilizzando ilAWS Lambda sito web AWS Prescriptive Guidance.