REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici - Principio di base dell'affidabilità

REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici

L'architettura orientata ai servizi (SOA) definisce servizi con funzioni ben delineate determinate dalle 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 delimitati e la progettazione dei sistemi si sposta verso architetture SOA o microservizi. Quando i monoliti vengono rifattorizzati, 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 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: alto

Guida all'implementazione

La decisione basata sul dominio (DDD) costituisce l'approccio fondamentale alla progettazione e alla creazione di software attorno 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 decisione basata sul dominio.

Decisione basata sul dominio

Passaggi dell'implementazione

  • I team possono organizzare eventi di event storming per identificare rapidamente eventi, comandi, aggregati e domini.

  • Una volta che le entità e le funzioni di dominio sono state definite in un contesto di dominio, puoi dividere il tuo dominio in servizi utilizzando il contesto delimitato, dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. 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.

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

  • Tecniche di strategia come il contesto a bolle consentono di introdurre la decisione basata sul dominio (DDD) in applicazioni esistenti o precedenti senza riscritture anticipate e impegni completi nei confronti di DDD. In un approccio basato sul contesto a bolle, viene stabilito un contesto delimitato utilizzando una mappatura e un coordinamento dei servizi, oppure il livello anti-danneggiamento (ACL), 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 utilizzare i servizi AWS per implementare la 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 focalizzare i servizi sulla risoluzione dei problemi aziendali.

  • Seleziona i servizi AWS che soddisfano al meglio i requisiti del tuo dominio aziendale e l' architettura di 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 su 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 i servizi AWS aiutano i team a concentrarsi sulla funzionalità del dominio e a migliorare la qualità del software.

Risorse

Best practice correlate:

Documenti correlati:

Esempi correlati:

Strumenti correlati: