Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Qualità fin dal design
L'adozione di un'architettura esagonale aiuta a promuovere la qualità della base di codice sin dall'inizio del progetto. È importante creare un processo che consenta di soddisfare i requisiti di qualità previsti sin dall'inizio, senza rallentare il processo di sviluppo.
Modifiche localizzate e maggiore leggibilità
L'utilizzo dell'approccio dell'architettura esagonale consente agli sviluppatori di modificare il codice in una classe o componente senza influire su altre classi o componenti. Questo design promuove la coesione dei componenti sviluppati. Disaccoppiando il dominio dagli adattatori e utilizzando interfacce note, è possibile aumentare la leggibilità del codice. Diventa più facile identificare problemi e casi isolati.
Questo approccio facilita anche la revisione del codice durante lo sviluppo e limita l'introduzione di modifiche o debiti tecnici non rilevati.
Testare innanzitutto la logica aziendale
I test locali possono essere eseguiti introducendo end-to-end, integrando e testando le unità nel progetto. End-to-endi test coprono l'intero ciclo di vita delle richieste in entrata. In genere richiamano un punto di ingresso dell'applicazione e verificano se ha soddisfatto i requisiti aziendali. Ogni progetto software dovrebbe avere almeno uno scenario di test che utilizzi input noti e produca gli output previsti. Tuttavia, l'aggiunta di altri scenari specifici può diventare complessa, poiché ogni test deve essere configurato per inviare una richiesta tramite un punto di ingresso (ad esempio, tramite un'API REST o delle code), passare attraverso tutti i punti di integrazione richiesti dall'azione aziendale e quindi affermare il risultato. La configurazione dell'ambiente per lo scenario di test e l'affermazione dei risultati possono richiedere molto tempo agli sviluppatori.
Nell'architettura esagonale, si verifica la logica aziendale in modo isolato e si utilizzano i test di integrazione per testare gli adattatori secondari. È possibile utilizzare adattatori fittizi o falsi nei test di logica aziendale. Puoi anche combinare i test per i casi d'uso aziendale con i test unitari per il tuo modello di dominio per mantenere una copertura elevata con un accoppiamento basso. Come buona prassi, i test di integrazione non dovrebbero convalidare la logica aziendale. Dovrebbero invece verificare che l'adattatore secondario chiami correttamente i servizi esterni.
Idealmente, è possibile utilizzare lo sviluppo basato su test (TDD) e iniziare a definire entità di dominio o casi d'uso aziendali con test appropriati all'inizio dello sviluppo. Scrivere innanzitutto i test consente di creare implementazioni fittizie delle interfacce richieste dal dominio. Quando i test hanno esito positivo e le regole logiche del dominio sono soddisfatte, è possibile implementare gli adattatori effettivi e distribuire il software nell'ambiente di test. A questo punto, l'implementazione della logica di dominio potrebbe non essere ideale. È quindi possibile lavorare sul refactoring dell'architettura esistente per farla evolvere introducendo modelli di progettazione o riorganizzando il codice in generale. Utilizzando questo approccio, è possibile evitare di introdurre bug di regressione e migliorare l'architettura man mano che il progetto cresce. Combinando questo approccio con i test automatici eseguiti nel processo di integrazione continua, è possibile ridurre il numero di potenziali bug prima che entrino in produzione.
Se utilizzi implementazioni serverless, puoi fornire rapidamente un'istanza dell'applicazione nel tuo AWS account per l'integrazione e il test manuali. end-to-end Dopo questi passaggi di implementazione, ti consigliamo di automatizzare i test con ogni nuova modifica inserita nel repository.
Manutenibilità
La manutenibilità si riferisce al funzionamento e al monitoraggio di un'applicazione per garantire che soddisfi tutti i requisiti e ridurre al minimo la probabilità di un guasto del sistema. Per rendere il sistema operativo, è necessario adattarlo al traffico o ai requisiti operativi futuri. È inoltre necessario assicurarsi che sia disponibile e facile da implementare con un impatto minimo o nullo sui client.
Per comprendere lo stato attuale e storico del sistema, è necessario renderlo osservabile. È possibile farlo fornendo metriche, registri e tracce specifici che gli operatori possono utilizzare per garantire che il sistema funzioni come previsto e per tenere traccia dei bug. Questi meccanismi dovrebbero inoltre consentire agli operatori di condurre l'analisi delle cause principali senza dover accedere alla macchina e leggere il codice.
Un'architettura esagonale mira ad aumentare la manutenibilità delle applicazioni Web in modo che il codice richieda complessivamente meno lavoro. Separando i moduli, localizzando le modifiche e separando la logica di business delle applicazioni dall'implementazione degli adattatori, è possibile produrre metriche e log che aiutano gli operatori a comprendere a fondo il sistema e a comprendere la portata delle modifiche specifiche apportate agli adattatori primari o secondari.
