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à.

Best practice

Modella il dominio aziendale

Passa dal dominio aziendale alla progettazione del software per assicurarti che il software che stai scrivendo soddisfi le esigenze aziendali.

Utilizza metodologie di progettazione basata sul dominio (DDD) come l'event storming per modellare il dominio aziendale. Event storming ha un formato di workshop flessibile. Durante il workshop, esperti di dominio e software esplorano in modo collaborativo la complessità del settore aziendale. Gli esperti di software utilizzano i risultati del workshop per avviare il processo di progettazione e sviluppo dei componenti software.

Scrivi ed esegui test fin dall'inizio

Utilizzate lo sviluppo basato sui test (TDD) per verificare la correttezza del software che state sviluppando. TDD funziona meglio a livello di test unitario. Lo sviluppatore progetta un componente software scrivendo prima un test, che richiama quel componente. Tale componente non ha alcuna implementazione all'inizio, quindi il test fallisce. Come passaggio successivo, lo sviluppatore implementa la funzionalità del componente, utilizzando dispositivi di test con oggetti fittizi per simulare il comportamento di dipendenze o porte esterne. Quando il test ha esito positivo, lo sviluppatore può continuare implementando adattatori reali. Questo approccio migliora la qualità del software e produce codice più leggibile, perché gli sviluppatori comprendono come gli utenti utilizzerebbero i componenti. L'architettura esagonale supporta la metodologia TDD separando il core dell'applicazione. Gli sviluppatori scrivono test unitari incentrati sul comportamento principale del dominio. Non devono scrivere adattatori complessi per eseguire i test; possono invece utilizzare semplici oggetti e dispositivi fittizi.

Utilizzate lo sviluppo basato sul comportamento (BDD) per garantire end-to-end l'accettazione a livello di funzionalità. In BDD, gli sviluppatori definiscono gli scenari per le funzionalità e li verificano con gli stakeholder aziendali. I test BDD utilizzano quanto più linguaggio naturale possibile per raggiungere questo obiettivo. L'architettura esagonale supporta la metodologia BDD con il suo concetto di adattatori primari e secondari. Gli sviluppatori possono creare adattatori primari e secondari che possono essere eseguiti localmente senza chiamare servizi esterni. Configurano la suite di test BDD per utilizzare l'adattatore primario locale per eseguire l'applicazione.

Esegui automaticamente ogni test nella pipeline di integrazione continua per valutare costantemente la qualità del sistema.

Definisci il comportamento del dominio

Scomponi il dominio in entità, oggetti di valore e aggregati (leggi come implementare la progettazione basata sul dominio) e definisci il loro comportamento. Implementa il comportamento del dominio in modo che i test scritti all'inizio del progetto abbiano esito positivo. Definisci i comandi che richiamano il comportamento degli oggetti di dominio. Definisci gli eventi che gli oggetti di dominio emettono dopo il completamento di un comportamento.

Definite le interfacce che gli adattatori possono utilizzare per interagire con il dominio.

Automatizza i test e l'implementazione

Dopo una prima dimostrazione concettuale, ti consigliamo di dedicare tempo all'implementazione DevOps delle pratiche. Ad esempio, le pipeline di integrazione e distribuzione continua (CI/CD) e gli ambienti di test dinamici aiutano a mantenere la qualità del codice ed evitare errori durante la distribuzione.

Scala il tuo prodotto utilizzando microservizi e CQRS

Se il tuo prodotto ha successo, scalalo scomponendo il progetto software in microservizi. Utilizzate la portabilità offerta dall'architettura esagonale per migliorare le prestazioni. Suddividi i servizi di interrogazione e i gestori di comandi in sincroni e asincroni separati. APIs Prendi in considerazione l'adozione del modello CQRS (Command Query Responsibility Segregation) e dell'architettura basata sugli eventi.

Se ricevi molte nuove richieste di funzionalità, valuta la possibilità di ridimensionare la tua organizzazione sulla base di modelli DDD. Strutturate i vostri team in modo che possiedano una o più funzionalità come contesti delimitati, come discusso in precedenza nella sezione. Scalabilità organizzativa Questi team possono quindi implementare la logica aziendale utilizzando l'architettura esagonale.

Progetta una struttura di progetto che si adatti ai concetti di architettura esagonale

L'infrastruttura come codice (IaC) è una pratica ampiamente adottata nello sviluppo del cloud. Consente di definire e gestire le risorse dell'infrastruttura (come reti, sistemi di bilanciamento del carico, macchine virtuali e gateway) come codice sorgente. In questo modo, è possibile tenere traccia di tutte le modifiche all'architettura utilizzando un sistema di controllo della versione. Inoltre, è possibile creare e spostare facilmente l'infrastruttura a scopo di test. Ti consigliamo di conservare il codice dell'applicazione e il codice dell'infrastruttura nello stesso repository quando sviluppi le tue applicazioni cloud. Questo approccio semplifica la manutenzione dell'infrastruttura per l'applicazione.

Si consiglia di dividere l'applicazione in tre cartelle o progetti che corrispondono ai concetti di architettura esagonale: entrypoints (adattatori primari), (dominio e interfacce) e domain (adattatori secondari). adapters

La seguente struttura di progetto fornisce un esempio di questo approccio per la progettazione di un'API su. AWS Il progetto mantiene il codice dell'applicazione (app) e il codice dell'infrastruttura (infra) nello stesso repository, come consigliato in precedenza.

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code 

Come discusso in precedenza, il dominio è il cuore dell'applicazione e non dipende da nessun altro modulo. Si consiglia di strutturare la domain cartella in modo da includere le seguenti sottocartelle:

Gli adattatori principali sono i punti di ingresso all'applicazione, rappresentati dalla entrypoints cartella. Questo esempio utilizza la api cartella come adattatore principale. Questa cartella contiene un'API model che definisce l'interfaccia richiesta dall'adattatore principale per comunicare con i client. La tests cartella contiene end-to-end i test per l'API. Si tratta di test superficiali che confermano che i componenti dell'applicazione sono integrati e funzionano in armonia.

Gli adattatori secondari, rappresentati dalla adapters cartella, implementano le integrazioni esterne richieste dalle porte di dominio. Un archivio di database è un ottimo esempio di adattatore secondario. Quando il sistema di database cambia, puoi scrivere un nuovo adattatore utilizzando l'implementazione definita dal dominio. Non è necessario modificare il dominio o la logica aziendale. La tests sottocartella contiene test di integrazione esterni per ogni adattatore.