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