Domain-Driven Design (DDD) è un approccio allo sviluppo software che si concentra sulla comprensione e sulla modellazione del dominio problematico all'interno del quale opera un sistema software. Sottolinea l’importanza di collaborare strettamente con esperti del settore per sviluppare una profonda comprensione delle complessità e delle complessità del settore. DDD fornisce una serie di principi, modelli e pratiche per aiutare gli sviluppatori a catturare ed esprimere in modo efficace i concetti di dominio nei loro progetti software.

conversione dell'oggetto in stringa

Argomenti importanti per il Domain-Driven Design (DDD)

• Che cos'è la progettazione guidata dal dominio (DDD)?
• Importanza della conoscenza del dominio
• Progettazione strategica nella progettazione guidata dal dominio (DDD)
• Modelli di progettazione tattica nella progettazione guidata dal dominio (DDD)
• Vantaggi della progettazione guidata dal dominio (DDD)
• Sfide della progettazione guidata dal dominio (DDD)
• Casi d'uso della progettazione guidata dal dominio (DDD)
• Esempio reale di Domain-Driven Design (DDD)

Che cos'è la progettazione guidata dal dominio (DDD)?

Dominio

Si riferisce all'area tematica o allo spazio problematico per cui il sistema software viene costruito. Comprende i concetti, le regole e i processi del mondo reale che il software è destinato a modellare o supportare. Ad esempio, in un'applicazione bancaria, il dominio include concetti come conti, transazioni, clienti e normative relative alle operazioni bancarie.

Guidato

Driven implica che la progettazione del sistema software sia guidata o influenzata dalle caratteristiche e dai requisiti del dominio. In altre parole, le decisioni di progettazione si basano su una profonda comprensione del dominio, anziché essere guidate esclusivamente da considerazioni tecniche o dettagli di implementazione.

Progetto

La progettazione si riferisce al processo di creazione di un piano o di un progetto per il sistema software. Ciò include decisioni su come sarà strutturato il sistema, come interagiranno i diversi componenti e come il sistema adempirà ai suoi compiti funzionale E non funzionale requisiti. Nel contesto del Domain-Driven Design, l'attenzione è rivolta alla progettazione del software in modo da riflettere accuratamente la struttura e il comportamento del dominio.

Domain-Driven Design è un concetto introdotto da un programmatore Eric Evans nel 2004 nel suo libro Progettazione basata sul dominio: affrontare la complessità nel cuore del software

Importanza della conoscenza del dominio

Supponiamo di aver progettato software utilizzando tutti gli stack tecnologici e le infrastrutture più recenti e che la nostra architettura di progettazione software sia sorprendente, ma quando rilasciamo questo software sul mercato, alla fine è l'utente finale a decidere se il nostro sistema è eccezionale o meno. Inoltre se il sistema non risolve le esigenze aziendali, allora non serve a nessuno. Non importa quanto sia bello o quanto sia buona l'architettura e l'infrastruttura.

Secondo Eric Evans Quando sviluppiamo software, la nostra attenzione non dovrebbe essere rivolta principalmente alla tecnologia, ma piuttosto al business. Ricordare,

Non è compito del cliente sapere cosa vuole – Steve Jobs

Progettazione strategica nella progettazione guidata dal dominio (DDD)

La progettazione strategica in Domain-Driven Design (DDD) si concentra sulla definizione dell'architettura e della struttura complessiva di un sistema software in modo da allinearsi al dominio problematico. Affronta preoccupazioni di alto livello come come organizzare i concetti di dominio, come suddividere il sistema in parti gestibili e come stabilire confini chiari tra i diversi componenti.

Vediamo alcuni concetti chiave all'interno della Progettazione Strategica in Domain-Driven Design (DDD)

1. Contesti delimitati

• Un contesto delimitato rappresenta un'area specifica all'interno del dominio problematico complessivo in cui un particolare modello o linguaggio si applica in modo coerente.
• Parti diverse di un sistema possono avere significati diversi per gli stessi termini e un contesto delimitato definisce confini espliciti entro i quali tali termini hanno significati specifici.
• Ciò consente ai team di sviluppare modelli adattati a contesti specifici senza introdurre confusione o incoerenze.
• I contesti delimitati aiutano a gestire la complessità suddividendo un dominio ampio e complesso in parti più piccole e più gestibili.

2. Mappatura del contesto

• La mappatura del contesto è il processo di definizione delle relazioni e delle interazioni tra diversi contesti delimitati.
• Si tratta di individuare aree di sovrapposizione o di integrazione tra contesti e di stabilire canali di comunicazione e accordi tra di essi.
• La mappatura del contesto aiuta a garantire che le diverse parti del sistema possano collaborare in modo efficace pur mantenendo confini chiari tra di loro.
• Esistono vari modelli e tecniche per la mappatura del contesto, come partnership, kernel condiviso e cliente-fornitore.

stringa in int

3. Modelli strategici

• I modelli strategici sono linee guida o principi generali per organizzare l'architettura di un sistema software in modo da allinearsi con il dominio del problema.
• Questi modelli aiutano ad affrontare le sfide comuni nella progettazione di sistemi complessi e forniscono approcci comprovati per strutturare il sistema in modo efficace.
• Esempi di modelli strategici includono aggregati, eventi di dominio e livello anticorruzione.
• Questi modelli forniscono soluzioni a problemi ricorrenti nella progettazione basata sul dominio e aiutano a garantire che l'architettura del sistema rifletta accuratamente i concetti di dominio sottostanti.

4. Kernel condiviso

• Il Kernel Condiviso è un modello strategico che prevede l'identificazione di aree comuni tra diversi Contesti Delimitati e la creazione di un sottoinsieme condiviso del modello di dominio che viene utilizzato da più contesti.
• Questo sottoinsieme condiviso, o kernel, aiuta a facilitare la collaborazione e l'integrazione tra contesti consentendo comunque a ciascun contesto di mantenere il proprio modello distinto.
• Il kernel condiviso deve essere utilizzato con giudizio, poiché introduce dipendenze tra contesti e può portare ad accoppiamenti se non gestito con attenzione.

5. Livello anticorruzione (ACL)

• Il livello anticorruzione è un altro modello strategico che aiuta a proteggere un sistema dall’influenza di sistemi esterni o legacy che utilizzano modelli o linguaggi diversi.
• Un ACL funge da livello di traduzione tra il sistema esterno e il modello di dominio principale, trasformando dati e messaggi secondo necessità per garantire la compatibilità.
• Ciò consente al modello del dominio principale di rimanere puro e focalizzato sul dominio problematico, pur continuando a integrarsi con i sistemi esterni, se necessario.

6. Linguaggio onnipresente

Il linguaggio ubiquo si riferisce a un vocabolario o linguaggio condiviso che viene utilizzato in modo coerente e universale da tutte le parti interessate coinvolte nello sviluppo di un sistema software. Questo linguaggio è costituito da termini, frasi e concetti che rappresentano accuratamente la conoscenza e i concetti del dominio.

Alcuni dei principi chiave dell’Ubiquitous Language sono:

• Comprensione condivisa : L'obiettivo principale di Ubiquitous Language è stabilire una comprensione condivisa del dominio problematico tra tutti i membri del team di sviluppo, inclusi sviluppatori, esperti di dominio, analisti aziendali e parti interessate. Utilizzando un linguaggio comune, tutti i soggetti coinvolti possono comunicare in modo più efficace e trasmettere con precisione concetti e requisiti del dominio.
• Coerenza e chiarezza : Il linguaggio ubiquo promuove la coerenza e la chiarezza nella comunicazione utilizzando una terminologia precisa e inequivocabile. Ogni termine o frase nella lingua dovrebbe avere un significato chiaro e concordato,
• Allineamento con i concetti aziendali : il linguaggio utilizzato in DDD deve essere strettamente in linea con la terminologia e i concetti utilizzati nel settore aziendale. Dovrebbe riflettere il modo in cui gli esperti del dominio pensano e parlano del dominio problematico, garantendo che il software rappresenti accuratamente concetti e processi del mondo reale.
• Natura evolutiva : Ubiquitous Language non è statico ma si evolve nel tempo man mano che il team acquisisce una comprensione più profonda del dominio e man mano che i requisiti cambiano. Dovrebbe adattarsi per riflettere nuove intuizioni, scoperte o cambiamenti nelle priorità aziendali, garantendo che il linguaggio rimanga pertinente e aggiornato durante tutto il processo di sviluppo.

Modelli di progettazione tattica nella progettazione guidata dal dominio (DDD)

Nel Domain-Driven Design (DDD), i modelli di progettazione tattica sono strategie o tecniche specifiche utilizzate per strutturare e organizzare il modello di dominio all'interno di un sistema software. Questi modelli aiutano gli sviluppatori a catturare in modo efficace la complessità del dominio, promuovendo al tempo stesso manutenibilità, flessibilità e scalabilità.

Vediamo alcuni dei principali modelli di progettazione tattica in DDD:

1. Entità

Un'entità è un oggetto di dominio che ha un'identità e un ciclo di vita distinti. Le entità sono caratterizzate dai loro identificatori univoci e dallo stato mutevole. Incapsulano comportamenti e dati relativi a un concetto specifico all'interno del dominio.

Ad esempio, in un'applicazione bancaria, aBankAccount>l'entità potrebbe avere proprietà come numero di conto, saldo e proprietario, insieme a metodi per depositare, prelevare o trasferire fondi.

2. Oggetto di valore

Un oggetto valore è un oggetto di dominio che rappresenta un valore concettualmente immutabile. A differenza delle entità, gli oggetti valore non hanno un'identità distinta e vengono generalmente utilizzati per rappresentare attributi o proprietà delle entità. Gli oggetti valore sono comparabili in base all'uguaglianza in base alle loro proprietà, piuttosto che alla loro identità.

Ad esempio, aMoney>L'oggetto valore potrebbe rappresentare un importo specifico di valuta, incapsulando proprietà come il tipo di valuta e l'importo.

3. Aggregato

• Un aggregato è un cluster di oggetti di dominio trattati come una singola unità ai fini della coerenza dei dati e dell'integrità delle transazioni.
• Gli aggregati sono costituiti da una o più entità e oggetti valore, con un'entità designata come radice aggregata.
• La radice dell'aggregato funge da punto di ingresso per accedere e modificare lo stato interno dell'aggregato.
• Gli aggregati impongono limiti di coerenza all'interno del modello di dominio, garantendo che le modifiche agli oggetti correlati vengano apportate in modo atomico.

Ad esempio, in un sistema di e-commerce, anOrder>l'aggregato potrebbe essere costituito da entità comeOrderItem>ECustomer>, con ilOrder>entità che funge da radice aggregata.

4. Deposito

• Un repository è un meccanismo per astrarre l'accesso ai dati e la logica di persistenza dal modello di dominio.
• I repository forniscono un'interfaccia standardizzata per interrogare e archiviare oggetti di dominio, nascondendo i dettagli su come i dati vengono recuperati o archiviati. I repository incapsulano la logica per la traduzione tra oggetti di dominio e meccanismi di archiviazione dei dati sottostanti, come database o servizi esterni.
• Disaccoppiando il modello di dominio dalle preoccupazioni relative all'accesso ai dati, i repository consentono una maggiore flessibilità e manutenibilità.

Ad esempio, aCustomerRepository>potrebbe fornire metodi per interrogare e archiviareCustomer>entità.

5. Fabbrica

• Una fabbrica è a modello creazionale utilizzato per incapsulare la logica per la creazione di istanze di oggetti di dominio complessi. Le fabbriche astraggono il processo di istanziazione degli oggetti, consentendo ai clienti di creare oggetti senza la necessità di conoscere i dettagli della loro costruzione.
• Le fabbriche sono particolarmente utili per creare oggetti che richiedono una logica di inizializzazione complessa o coinvolgono più passaggi.

Ad esempio, aProductFactory>potrebbe essere responsabile della creazione di istanze diProduct>entità con configurazioni predefinite.

6. Servizio

• Un servizio è un oggetto di dominio che rappresenta un comportamento o un'operazione che non appartiene naturalmente a nessuna entità specifica o oggetto valore.
• I servizi incapsulano la logica del dominio che opera su più oggetti o orchestra le interazioni tra oggetti.
• I servizi sono generalmente stateless e si concentrano sull'esecuzione di attività specifiche o sull'applicazione di regole di dominio.

Ad esempio, unOrderService>potrebbe fornire metodi per elaborare gli ordini, applicare sconti e calcolare i costi di spedizione.

Vantaggi della progettazione guidata dal dominio (DDD)

• Comprensione condivisa :
  • Incoraggia la collaborazione tra esperti di dominio, sviluppatori e parti interessate.
  • Incoraggiando una comprensione condivisa dell'ambito problematico attraverso il linguaggio onnipresente, i team possono comunicare in modo più efficace e garantire che il software rifletta accuratamente le esigenze e i requisiti dell'azienda.
• Concentrarsi sul dominio principale :
  • Aiuta i team a identificare e dare priorità al dominio principale dell'applicazione, ovvero le aree del sistema che forniscono il massimo valore all'azienda. Concentrando gli sforzi di sviluppo sul dominio principale, i team possono fornire funzionalità che affrontano direttamente gli obiettivi aziendali e differenziano il software dalla concorrenza.
• Resilienza al cambiamento :
  • Enfatizza la progettazione di sistemi software resilienti al cambiamento modellando il dominio in modo da riflettere le complessità e le incertezze intrinseche del dominio problematico.
  • Abbracciando il cambiamento come parte naturale dello sviluppo software, i team possono rispondere in modo più efficace all'evoluzione delle esigenze aziendali e delle condizioni di mercato.
• Chiara separazione delle preoccupazioni :
  • DDD incoraggia una chiara separazione delle preoccupazioni tra logica del dominio, preoccupazioni sull'infrastruttura e preoccupazioni sull'interfaccia utente. Isolando la logica del dominio dai dettagli tecnici e dai problemi dell'infrastruttura, i team possono mantenere un modello di dominio pulito e mirato, indipendente da specifici dettagli di implementazione o scelte tecnologiche.
• Testabilità migliorata :
  • Promuove l'uso di oggetti di dominio con confini e comportamenti ben definiti, rendendo più semplice scrivere test migliori e mirati che verifichino la correttezza della logica del dominio.
  • Progettando sistemi software tenendo presente la testabilità, i team possono garantire che le modifiche alla base di codice siano sicure e prevedibili, riducendo il rischio di introdurre regressioni o effetti collaterali indesiderati.
• Supporto per regole aziendali complesse :
  • Fornisce modelli e tecniche per modellare e implementare regole aziendali e flussi di lavoro complessi all'interno del modello di dominio.
  • Rappresentando esplicitamente le regole aziendali nel modello di dominio, i team possono garantire che il software rifletta accuratamente le complessità del dominio aziendale e applichi vincoli e requisiti specifici del dominio.
• Allineamento agli obiettivi aziendali :
  • In definitiva, mira ad allineare gli sforzi di sviluppo del software con gli scopi e gli obiettivi strategici dell'azienda. Concentrandosi sulla comprensione e sulla modellazione dell'ambito problematico, i team possono fornire soluzioni software che supportano direttamente gli obiettivi aziendali, guidano l'innovazione e creano valore per le parti interessate e gli utenti finali.

Sfide della progettazione guidata dal dominio (DDD)

• Complessità :
  • Il DDD può introdurre complessità, soprattutto in domini ampi e complessi.
  • La modellazione accurata di domini aziendali complessi richiede una profonda comprensione del dominio e può implicare la gestione di ambiguità e incertezze. Gestire questa complessità in modo efficace richiede un’attenta pianificazione, collaborazione e competenza.
• Adozione onnipresente della lingua :
  • Stabilire e mantenere un linguaggio onnipresente, un vocabolario condiviso che rappresenti accuratamente i concetti di dominio, può essere una sfida. Richiede la collaborazione tra sviluppatori ed esperti di dominio per identificare e concordare termini e significati del dominio.
  • Raggiungere il consenso sul linguaggio onnipresente può richiedere il superamento delle barriere comunicative e la riconciliazione delle differenze terminologiche e di prospettive.
• Allineamento del contesto delimitato :
  • In domini ampi e complessi, parti diverse del dominio possono avere modelli distinti e contesti delimitati. Allineare questi contesti delimitati e garantire la coerenza tra loro può essere difficile.
  • Richiede una chiara comunicazione, collaborazione e coordinamento tra i team che lavorano su diverse parti del dominio per evitare incoerenze e conflitti.
• Complessità tecnica :
  • L’implementazione efficace dei principi e dei modelli DDD può richiedere l’adozione di nuove tecnologie, strutture e approcci architettonici. L'integrazione di DDD con sistemi esistenti o basi di codice legacy può essere complessa e potrebbe richiedere il refactoring o la riprogettazione del codice esistente per allinearlo ai principi DDD.
  • Le sfide tecniche quali prestazioni, scalabilità e manutenibilità devono essere affrontate con attenzione per garantire il successo dell'adozione del DDD.
• Resistenza al cambiamento :
  • L'introduzione del DDD può incontrare resistenza da parte dei membri del team che sono abituati agli approcci di sviluppo tradizionali o che percepiscono il DDD come eccessivamente complesso o poco pratico.
  • Superare la resistenza al cambiamento richiede comunicazione, formazione e leadership efficaci per dimostrare i vantaggi del DDD e affrontare preoccupazioni e scetticismo.
• Eccessiva ingegneria :
  • Esiste il rischio di un'ingegneria eccessiva quando si applica DDD, in cui i team si concentrano troppo sulla modellazione di concetti di dominio complessi e sull'introduzione di astrazioni o complessità non necessarie. Trovare il giusto equilibrio tra semplicità ed espressività è fondamentale per evitare di complicare eccessivamente la progettazione e l'implementazione.

Casi d'uso della progettazione guidata dal dominio (DDD)

• Finanza e banche :
  • Nel settore finanziario, la DDD può essere utilizzata per modellare strumenti finanziari, transazioni e requisiti normativi complessi. Rappresentando accuratamente concetti di dominio come conti, transazioni e portafogli, DDD aiuta a garantire l'integrità e la coerenza dei sistemi finanziari. Consente inoltre una migliore gestione del rischio, conformità e reporting.
• Commercio elettronico e vendita al dettaglio :
  • Le piattaforme di e-commerce spesso affrontano concetti di dominio complessi come cataloghi di prodotti, gestione dell'inventario, prezzi e ordini dei clienti. DDD può aiutare a modellare questi concetti in modo efficace, abilitando funzionalità come consigli personalizzati, prezzi dinamici ed elaborazione semplificata degli ordini.
• Sanità e scienze della vita :
  • Nel settore sanitario, il DDD può essere utilizzato per modellare cartelle cliniche, diagnosi mediche, piani di trattamento e flussi di lavoro sanitari. Rappresentando accuratamente concetti di dominio come dati demografici dei pazienti, anamnesi mediche e protocolli clinici, DDD consente lo sviluppo di robusti sistemi di cartelle cliniche elettroniche (EHR), piattaforme di imaging medico e applicazioni di telemedicina.
• Assicurazione :
  • Le compagnie assicurative gestiscono diversi prodotti, polizze, sinistri e processi di sottoscrizione. DDD può aiutare a modellare questi concetti di dominio complessi, abilitando funzionalità come la gestione delle politiche, l'elaborazione dei sinistri, la valutazione del rischio e l'analisi attuariale.
• Gestione immobiliare e immobiliare :
  • La gestione immobiliare e immobiliare implica la gestione di diverse proprietà, locazioni, inquilini, richieste di manutenzione e transazioni finanziarie. DDD può aiutare a modellare questi concetti di dominio in modo efficace, abilitando funzionalità come elenchi di proprietà, gestione dei contratti di locazione, portali degli inquilini e monitoraggio delle risorse.

Esempio reale di Domain-Driven Design (DDD)

Dichiarazione problema

Diciamo che stiamo sviluppando un'applicazione di ride-hailing chiamata RideX. Il sistema consente agli utenti di richiedere corse, agli autisti di accettare richieste di corse e facilita il coordinamento delle corse tra utenti e autisti.

elenco ordina java

Lingua onnipresente

1. Utente : si riferisce alle persone che richiedono corse tramite la piattaforma RideX.
2. Autista : si riferisce alle persone che forniscono corse agli utenti tramite la piattaforma RideX.
3. Richiesta di corsa : rappresenta la richiesta di un passaggio da parte di un utente, specificando dettagli come luogo di ritiro, destinazione e preferenze di corsa.
4. Passeggiata : rappresenta una singola istanza di una corsa, inclusi dettagli come luoghi di ritiro e riconsegna, tariffa e durata.
5. Stato della corsa : rappresenta lo stato corrente di una corsa, ad esempio Richiesto, Accettato, In corso o Completato.

Contesti delimitati

1. Contesto della gestione delle corse : responsabile della gestione del ciclo di vita delle corse, comprese le richieste di corse, l'assegnazione delle corse ai conducenti e gli aggiornamenti sullo stato delle corse.
2. Contesto di gestione degli utenti : gestisce l'autenticazione dell'utente, la registrazione e le funzionalità specifiche dell'utente come la cronologia delle corse e i metodi di pagamento.
3. Contesto di gestione dei conducenti : gestisce l'autenticazione del conducente, la registrazione, lo stato di disponibilità e le funzionalità specifiche del conducente come guadagni e valutazioni.

Entità e oggetti valore

1. Entità utente : rappresenta un utente registrato della piattaforma RideX, con proprietà come ID utente, e-mail, password e informazioni di pagamento.
2. Entità conducente : rappresenta un conducente registrato sulla piattaforma RideX, con proprietà come ID conducente, dettagli del veicolo e stato del conducente.
3. Entità della richiesta di corsa : rappresenta la richiesta di una corsa da parte di un utente, incluse proprietà come ID richiesta, luogo di ritiro, destinazione e preferenze di corsa.
4. Entità di corsa : rappresenta una singola istanza di una corsa, incluse proprietà come ID della corsa, luoghi di ritiro e riconsegna, tariffa e stato della corsa.
5. Oggetto Valore Posizione : Rappresenta una posizione geografica, con proprietà come latitudine e longitudine.

Aggregati

1. Giro aggregato : è costituito dall'entità corsa come radice aggregata, insieme alle entità correlate come le entità Richiesta corsa, Utente e Conducente. Il Ride Aggregate incapsula la logica per la gestione del ciclo di vita di una corsa, inclusa la gestione delle richieste di corsa, l'assegnazione dei conducenti e l'aggiornamento dello stato della corsa.

Deposito

1. Deposito di corse : fornisce metodi per interrogare e archiviare entità correlate alla corsa, come il recupero dei dettagli della corsa, l'aggiornamento dello stato della corsa e la memorizzazione dei dati relativi alla corsa nel database.

Servizi

1. Servizio di assegnazione delle corse : responsabile dell'assegnazione dei conducenti disponibili alle richieste di corsa in base a fattori quali la disponibilità del conducente, la vicinanza al luogo di ritiro e le preferenze dell'utente.
2. Servizio di pagamento : gestisce l'elaborazione dei pagamenti per le corse completate, il calcolo delle tariffe, l'elaborazione dei pagamenti e l'aggiornamento delle informazioni di pagamento dell'utente e del conducente.

Eventi del dominio

1. RideRequestedEvent : rappresenta un evento attivato quando un utente richiede una corsa, contenente informazioni come i dettagli della richiesta di corsa e l'ID utente.
2. Evento RideAccepted : rappresenta un evento attivato quando un conducente accetta una richiesta di corsa, contenente informazioni come l'ID della corsa, l'ID del conducente e il luogo di ritiro.

Scenario di esempio

1. Utente che richiede una corsa : un utente richiede una corsa fornendo il luogo di ritiro, la destinazione e le preferenze di corsa. RideX crea una nuova entità di richiesta di corsa e attiva un RideRequestedEvent.
2. Autista che accetta un passaggio : un conducente accetta una richiesta di corsa dalla piattaforma RideX. RideX aggiorna lo stato della corsa su Accettato, assegna l'autista alla corsa e attiva un RideAcceptedEvent.
3. Giro in corso : l'utente e l'autista coordinano la corsa, con lo stato della corsa che passa da Accettato a In corso una volta che l'autista raggiunge il luogo di ritiro.
4. Completamento della corsa : Dopo aver raggiunto la destinazione, lo stato della corsa viene aggiornato su Completato. RideX calcola la tariffa, elabora il pagamento e aggiorna di conseguenza le informazioni di pagamento dell'utente e del conducente.