# 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](https://martinfowler.com/bliki/BoundedContext.html) 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.](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png) ## Passaggi dell'implementazione + I team possono organizzare eventi di [event storming](https://serverlessland.com/event-driven-architecture/visuals/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](https://martinfowler.com/bliki/BoundedContext.html), 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](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) 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](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 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)](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), 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](https://aws.amazon.com/microservices/) che soddisfano al meglio i requisiti del tuo dominio aziendale e l' [architettura di microservizi](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html): + [AWS Serverless](https://aws.amazon.com/serverless/) consente al team di concentrarsi su una logica di dominio specifica anziché sulla gestione di server e infrastrutture. + [I container in AWS](https://aws.amazon.com/containers/) semplificano la gestione della tua infrastruttura, in modo da poterti concentrare sui requisiti del tuo dominio. + [I database dedicati](https://aws.amazon.com/products/databases/) ti aiutano ad adattare i requisiti del tuo dominio al tipo di database più idoneo. + [La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) 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:** + [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) + [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md) **Documenti correlati:** + [Microservizi AWS](https://aws.amazon.com/microservices/) + [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html) + [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) + [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Progettazione basata sul dominio: affrontare la complessità al cuore del software) ](https://www.amazon.com/gp/product/0321125215) + [ La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) + [ Scomporre i monoliti in microservizi ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) + [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming) + [ Messaggi tra contesti limitati ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context) + [ Microservizi ](https://www.martinfowler.com/articles/microservices.html) + [ Sviluppo basato su test ](https://en.wikipedia.org/wiki/Test-driven_development) + [ Sviluppo basato sul comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development) **Esempi correlati:** + [ Workshop sul cloud aziendale nativo ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US) + [ Progettazione di microservizi cloud nativi su AWS (da DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main) **Strumenti correlati:** + [ Database su Cloud AWS](https://aws.amazon.com/products/databases/) + [ Serverless su AWS](https://aws.amazon.com/serverless/) + [ Container in AWS](https://aws.amazon.com/containers/)