REL03-BP02 Crea servizi incentrati su domini e funzionalità aziendali specifici - AWS Well-Architected Framework

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

REL03-BP02 Crea servizi incentrati su domini e funzionalità aziendali specifici

Le architetture orientate ai servizi (SOA) definiscono servizi con funzioni ben delineate definite in base alle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per tracciare i limiti dei servizi lungo i confini del contesto aziendale. Concentrarsi sui domini e sulle funzionalità aziendali aiuta i team a definire requisiti di affidabilità indipendenti per i propri servizi. I contesti delimitati isolano e incapsulano la logica aziendale, consentendo ai team di ragionare meglio su come gestire gli errori.

Risultato desiderato: ingegneri e parti interessate aziendali definiscono congiuntamente contesti delimitati e li utilizzano per progettare sistemi come servizi che soddisfano funzioni aziendali specifiche. Questi team utilizzano pratiche consolidate come l'event storming per definire i requisiti. Le nuove applicazioni sono concepite come servizi con confini ben definiti e con accoppiamento debole. I monoliti esistenti vengono scomposti in contesti limitati e i progetti di sistema si spostano verso architetture a microservizi. SOA In caso di rifattorizzazione dei monoliti, vengono applicati approcci consolidati come contesti a bolle e schemi di decomposizione dei monoliti.

I servizi orientati al dominio vengono eseguiti come uno o più processi che non condividono lo stato. Rispondono in modo indipendente alle fluttuazioni della domanda e gestiscono gli scenari di errore alla luce dei requisiti specifici del dominio.

Anti-pattern comuni:

  • I team sono formati su domini tecnici specifici come UI e UX, middleware (software intermediario) o database anziché su domini aziendali specifici.

  • Le applicazioni coprono le responsabilità di dominio. I servizi che coprono contesti delimitati possono essere più difficili da gestire, richiedere maggiori sforzi di test ed esigere la partecipazione di più team di dominio agli aggiornamenti software.

  • Le dipendenze a livello di dominio, come le librerie di entità di dominio, sono condivise tra i servizi, in modo che le modifiche per il dominio di un servizio richiedano modifiche ad altri domini dei servizi.

  • I contratti di servizio e la logica aziendale non esprimono le entità in un linguaggio di dominio comune e coerente, con il risultato di livelli di traduzione che complicano i sistemi e aumentano le attività di debug.

Vantaggi dell'adozione di questa best practice: le applicazioni sono progettate come servizi indipendenti limitati da domini aziendali e utilizzano un linguaggio aziendale comune. I servizi sono testabili e implementabili in modo indipendente. I servizi soddisfano i requisiti di resilienza specifici del dominio implementato.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all'implementazione

La progettazione basata sul dominio (DDD) è l'approccio fondamentale per la progettazione e la creazione di software in base ai domini aziendali. È utile utilizzare un framework esistente quando si creano servizi incentrati sui domini aziendali. Quando si utilizzano applicazioni monolitiche esistenti, è possibile sfruttare i modelli di decomposizione che forniscono tecniche consolidate per modernizzare le applicazioni in servizi.

Diagramma di flusso che illustra l'approccio incentrato sulla progettazione basata sul dominio.

Progettazione basata sul dominio

Passaggi dell'implementazione

  • I team possono organizzare workshop di event storming per identificare rapidamente eventi, comandi, aggregati e domini in un formato leggero simile a quello delle note adesive.

  • Una volta create le entità e le funzioni di dominio in un contesto di dominio, puoi suddividere il dominio in servizi mediante il contesto delimitato, che raggruppa entità con funzionalità e attributi simili. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.

    • Ad esempio, le entità del sito Web Amazon.com possono includere elementi quali pacchetti, distribuzione, pianificazione, prezzo, sconto e valuta.

    • Il pacchetto, la distribuzione e la pianificazione sono raggruppati nel contesto di spedizione, mentre il prezzo, lo sconto e la valuta sono raggruppati nel contesto dei prezzi.

  • La scomposizione dei monoliti in microservizi delinea i modelli per rifattorizzare i microservizi. L'utilizzo di modelli per la decomposizione in base a capacità aziendale, sottodominio o transazione si allinea bene agli approcci basati sul dominio.

  • Le tecniche tattiche, come il bubble context, consentono di introdurre applicazioni esistenti o legacy senza riscritture iniziali e impegni completi DDD in tal senso. DDD In un approccio basato sul contesto delle bolle, si crea un contesto ristretto e delimitato mediante un livello di mappatura e coordinamento dei servizi o il livello anticorruzione, che protegge il modello di dominio appena definito dalle influenze esterne.

Dopo aver eseguito l'analisi del dominio e definito le entità e i contratti di servizio, i team possono sfruttare i AWS servizi per implementare la loro progettazione basata sul dominio come servizi basati sul cloud.

  • Inizia a sviluppare definendo test che applichino le regole aziendali del tuo dominio. Lo sviluppo basato sui test (TDD) e lo sviluppo basato sul comportamento (BDD) aiutano i team a mantenere i servizi concentrati sulla risoluzione dei problemi aziendali.

  • Seleziona i servizi AWS ideali per i requisiti del tuo dominio aziendale e l'architettura dei microservizi:

    • AWS Serverless consente al team di concentrarsi su una logica di dominio specifica anziché sulla gestione di server e infrastrutture.

    • I container in AWS semplificano la gestione della tua infrastruttura, in modo da poterti concentrare sui requisiti del tuo dominio.

    • I database dedicati ti aiutano ad adattare i requisiti del tuo dominio al tipo di database più idoneo.

  • La creazione di architetture esagonali in AWS delinea un framework per integrare la logica aziendale nei servizi che funzionano a ritroso da un dominio aziendale per soddisfare i requisiti funzionali e, quindi, per collegare adattatori di integrazione. I modelli che separano i dettagli dell'interfaccia dalla logica aziendale con AWS i servizi aiutano i team a concentrarsi sulle funzionalità del dominio e a migliorare la qualità del software.

Risorse

Best practice correlate:

Documenti correlati:

Esempi correlati:

Strumenti correlati: