Informazioni su questo e-book

EPUB è un formato aperto e standard di settore per gli e-book. Tuttavia, il supporto per EPUB e
le sue numerose funzionalità varia a seconda dei dispositivi di lettura e delle applicazioni. Usa le
impostazioni del dispositivo o dell'app per personalizzare la presentazione a tuo piacimento. Le
impostazioni che è possibile personalizzare spesso includono il tipo di carattere, la dimensione del
carattere, la colonna singola o doppia, la modalità orizzontale o verticale e le figure su cui è
possibile fare clic o toccare per ingrandire. Per ulteriori informazioni sulle impostazioni e le
funzionalità del dispositivo o dell'app di lettura, visitare il sito Web del produttore del dispositivo.
Molti titoli includono esempi di codice di programmazione o di configurazione. Per ottimizzare
la presentazione di questi elementi, visualizzare l'e-book in modalità orizzontale a colonna singola
e impostare la dimensione del carattere in base all'impostazione più piccola. Oltre a presentare
codice e configurazioni nel formato di testo adattabile, abbiamo incluso immagini del codice che
imitano la presentazione trovata nel libro di stampa; pertanto, quando il formato adattabile può
compromettere la presentazione del listato di codice, verrà visualizzato un collegamento "Fare clic
qui per visualizzare l'immagine del codice". Fare clic sul collegamento per visualizzare l'immagine
del codice di fedeltà di stampa. Per tornare alla pagina precedente visualizzata, fai clic sul pulsante
Indietro sul dispositivo o sull'app.
Progettazione basata su dominio distillata

Vaughn Vernon

Boston , Columbus , Indianapoli , New York , San Francisco , Amsterdam , Città del Capo
Dubai , Londra , Madrid , Milano , Parigi , Parigi , Toronto , Toronto , San Paolo, Sydney ,
Hong Kong , Singapore , Taipei , Tokyo
Molte delle designazioni utilizzate da produttori e venditori per distinguere i loro prodotti sono
rivendicate come marchi. Se tali designazioni compaiono in questo libro, e l'editore era a
conoscenza di una rivendicazione di marchio, le denominazioni sono state stampate con lettere
maiuscole iniziali o in maiuscolo.
L'autore e l'editore si sono presi cura nella preparazione di questo libro, ma non hanno alcuna
garanzia espressa o implicita di alcun tipo e non si assumono alcuna responsabilità per errori o
omissioni. Nessuna responsabilità è assunta per danni accidentali o conseguenti in relazione o
derivanti dall'uso delle informazioni o dei programmi contenuti nel presente documento.
Per informazioni sull'acquisto di questo titolo in quantità collettive o per opportunità di vendita
speciali (che possono includere versioni elettroniche, disegni di copertine personalizzati e
contenuti specifici per la tua attività, obiettivi di formazione, attenzione al marketing o interessi
di branding), si prega di contattare il nostro reparto vendite aziendale a
corpsales@pearsoned.com o (800) 382-3419.
Per le richieste di vendita del governo, contattare governmentsales@pearsoned.com .
Per domande sulle vendite al di fuori degli Stati Uniti, contattare intlcs@pearson.com .
Visitateci sul Web: informit.com/aw
Numero di controllo della Biblioteca del Congresso: 2016936587
Diritto d'© 2016 Pearson Education, Inc.
Tutti i diritti riservati. Stampato negli Stati Uniti d'America. Questa pubblicazione è protetta da
copyright e l'autorizzazione deve essere ottenuta dall'editore prima di qualsiasi riproduzione
vietata, conservazione in un sistema di recupero o trasmissione in qualsiasi forma o con qualsiasi
mezzo, elettronico, meccanico, fotocopiatoria, registrazione o simili. Per informazioni sulle
autorizzazioni, i moduli di richiesta e i contatti appropriati all'interno del dipartimento Diritti
globali e autorizzazioni di Pearson Education, visitare www.pearsoned.com/permissions/ .
ISBN-13: 978-0-13-443442-1
ISBN-10: 0-13-443442-0
Testo stampato negli Stati Uniti su carta riciclata presso RR Donnelley a Crawfordsville,
Indiana. Prima stampa, maggio 2016
Nicole e Tristan
L'abbiamo fatto di nuovo!
Contenuto

Prefazione
Riconoscimenti
Informazioni sull'autore
Capitolo 1 DDD per me
DDD farà male?
Design buono, cattivo ed efficace
Progettazione strategica
Progettazione tattica
Il processo di apprendimento e la raffinazione delle conoscenze
Iniziamo!
Capitolo 2 Progettazione strategica con contesti delimitati e linguaggio onnipresente
Esperti di dominio e driver di business
Caso di studio
Necessaria progettazione strategica fondamentale
Sfida e Unify
Sviluppare un linguaggio onnipresente
Mettere gli scenari al lavoro
E il Long Haul?
Architettura
Riepilogo
Capitolo 3 Progettazione strategica con sottodomini
Che cos'è un sottodominio?
Tipi di sottodomini
Affrontare la complessità
Riepilogo
Capitolo 4 Progettazione strategica con mappatura del contesto
Tipi di mapping
Partenariato
Kernel condiviso
Cliente-Fornitore
Conformista
Strato di anticorruzione
 Aprire il servizio hostOpen Host Service
Lingua pubblicata
Modi separati
Grande palla di fango
Fare buon uso della mappatura del contesto
RPC con SOAP
RESTful HTTP
Messaggistica
Esempio di mapping del contesto
Riepilogo
Capitolo 5 Progettazione tattica con
aggregati Perché utilizzati
Aggregate Rules of Thumb
Regola 1: Proteggere le invarianti aziendali all'interno di limiti aggregatiRule 1:
Protect Business Invariants inside Aggregate Boundaries
Regola 2: Progettare aggregazioni di piccole dimensioni
Regola 3: Riferimento ad altre aggregazioni solo per identità
Regola 4: Aggiornare altre aggregazioni usando eventuali
aggregazioni di modellazione coerenza
Scegli attentamente le tue astrazioni
Aggregazioni di ridimensionamento a destra
Unità teabili
Riepilogo
Capitolo 6 Progettazione tattica con eventi di dominio
Progettazione, implementazione e utilizzo di eventi di dominio
Approvvigionamento eventi
Riepilogo
Capitolo 7 Strumenti di accelerazione e gestione
Storming di eventi
Altri strumenti
Gestione di DDD in Agile un progettoGestione DDD in un progetto Agile
Le prime cose prima di tutto
Utilizzare l'analisi SWOT
Picchi di modellazione e modellazione del debito
 Identificazione delle attività e stima dello sforzo
Modellazione timeboxed
Come implementare
 Interazione con gli esperti di dominio
Riepilogo
Riferimenti
Indice
Prefazione

Perché la costruzione di modelli è un'attività così divertente e gratificante? Fin da quando ero
bambino ho amato costruire modelle. A quel tempo costruivo per lo più modelli di auto e aerei. Si
è verificato un problema sconosciuto. Eppure, LEGO è stato una parte importante della vita di mio
figlio fin da quando era molto giovane. È così affascinante concepire e costruire modelli con quei
piccoli mattoni. E 'facile venire con modelli di base, e sembra che si può estendere le vostre idee
quasi all'infinito.
Probabilmente si può relazionarsi con una sorta di costruzione di modello giovanile.
I modelli si verificano in tante situazioni nella vita. Se ti piace giocare ai giochi da tavolo, stai
usando i modelli. Potrebbe essere un modello di immobili e proprietari di proprietà, o modelli di isole
e sopravvissuti, o modelli di territori e attività edilizie, e chissà cosa tutti. Allo stesso modo, i
videogiochi sono modelli.
Forse modellano un mondo fantastico con personaggi fantasiosi che giocano ruoli fantastici. Un
mazzo di carte e la potenza del modello di giochi correlati. Usiamo i modelli tutto il tempo e
probabilmente così spesso che non diamo alla maggior parte dei modelli un meritato
riconoscimento. Le modelle sono solo una parte della nostra vita.
Ma perché? Ogni persona ha uno stile di apprendimento. Ci sono un certo numero di stili di
apprendimento, ma tre dei più discussi sono stili uditivi, visivi e tattili. Gli studenti uditivi
imparano ascoltando e ascoltando. Gli studenti visivi imparano leggendo o vedendo le immagini.
Gli studenti tattili imparano facendo qualcosa che comporta toccare. È interessante notare che
ogni stile di apprendimento è fortemente favorito dall'individuo nella misura in cui lui o lei a
volte può avere problemi con altri tipi di apprendimento. Per esempio, gli studenti tattili
probabilmente ricordano ciò che hanno fatto, ma potrebbero avere problemi a ricordare ciò che
è stato detto durante il processo. Con la costruzione di modelli, si potrebbe pensare che gli
studenti visivi e tattili avrebbero un enorme vantaggio rispetto agli studenti uditivi, perché la
costruzione del modello sembra coinvolgere principalmente la stimolazione visiva e tattile.
Tuttavia, questo potrebbe non essere sempre vero, soprattutto se un team di costruttori di
modelli utilizza la comunicazione udibile nel processo di costruzione. In altre parole, la
costruzione del modello offre la possibilità di adattarsi allo stile di apprendimento della
stragrande maggioranza degli individui.
Con la nostra naturale affinità con l'apprendimento attraverso la costruzione di modelli,
perché non dovremmo naturalmente desiderare di modellare il software che sempre più assiste
e influenza le nostre vite? Infatti, per modellare il software sembra essere, beh, umano. E il
software modello dovremmo. Mi sembra che gli esseri umani dovrebbero essere costruttori di
modelli software d'elite.
È il mio forte desiderio di aiutarvi ad essere il più umano possibile da software di modellazione
utilizzando alcuni dei migliori strumenti di modellazione software disponibili. Questi strumenti sono
inclusi nel pacchetto "Domain-Driven Design" o DDD. Questo toolbox, in realtà una serie di modelli, è
stato codificato per la prima volta da Eric Evans nel libro Progettazione basata su domini: affrontare la
complessità nel cuore del software [DDD] . La mia visione è quella di portare DDD a tutti possibile. Per
fare il mio punto, se devo dire che voglio portare
DDD alle masse, allora così sia. Questo è dove DDD merita di essere, e DDD è la cassetta degli
attrezzi che gli esseri umani orientati al modello meritano di utilizzare per creare i loro modelli
software più avanzati. Con questo libro, sono determinato a rendere l'apprendimento e l'utilizzo
di DDD il più semplice e semplice possibile e di portarlo al pubblico più ampio possibile.
Per gli studenti uditivi, DDD offre la prospettiva di imparare attraverso la comunicazione del
team di costruire un modello basato sullo sviluppo di un linguaggio onnipresente. Per gli
studenti visivi e tattili, il processo di utilizzo degli strumenti DDD è molto visivo e pratico in
quanto la tua squadra modella sia strategicamente che tatticamente. Ciò è particolarmente vero
quando si disegnano mappe di contesto e si modellano
processo di business utilizzando Evento Storming. Così, credo che DDD può sostenere tutti coloro
che vogliono imparare e raggiungere la grandezza attraverso la costruzione di modelli.

A chi serve questo libro?

Questo libro è per tutti coloro che sono interessati ad apprendere gli aspetti e gli strumenti DDD più
importanti e ad apprendere rapidamente. I lettori più comuni sono architetti software e sviluppatori
di software che metteranno DDD in pratica nei progetti. Molto spesso, gli sviluppatori di software
scoprono rapidamente la bellezza di DDD e sono fortemente attratti dai suoi potenti strumenti.
Anche così, ho reso il tema comprensibile per dirigenti, esperti di dominio, manager, business
analyst, architetti dell'informazione e tester allo stesso modo. Non c'è davvero alcun limite a quelli
nel settore delle tecnologie dell'informazione (IT) e degli ambienti di ricerca e sviluppo (R&S) che
possono trarre vantaggio dalla lettura di questo libro.
Se sei un consulente e stai lavorando con un cliente a cui hai consigliato l'uso di DDD, fornisci
questo libro come un modo per portare rapidamente le principali parti interessate alla velocità. Se
hai sviluppatori, magari junior o midlevel o anche senior, che lavorano al tuo progetto che non
hanno familiarità con DDD ma hanno bisogno di usarlo molto presto, assicurati di leggere questo
libro. Leggendo questo libro, come minimo, tutte le parti interessate del progetto e gli sviluppatori
avranno il vocabolario e comprendere gli strumenti DDD primari in uso. Questo permetterà loro di
condividere le cose in modo significativo mentre spostano il progetto in avanti.
Qualunque sia il tuo livello di esperienza e il tuo ruolo, leggi questo libro e poi esercitati con
DDD su un progetto. In seguito, rileggi questo libro e scopri cosa puoi imparare dalle tue
esperienze e dove puoi migliorare in futuro.

Cosa copre questo libro

Il primo capitolo, "DDD for Me", spiega cosa può fare DDD per te e la tua organizzazione e
fornisce una panoramica più dettagliata di ciò che imparerai e perché è importante.
Capitolo 2 " "Progettazione strategica con contesti delimitati e linguaggio onnipresente ",
Introdurre
DDD progettazione strategica e insegna i capisaldi del DDD, dei contesti delimitati e del
linguaggio onnipresente. Il capitolo 3 , "Progettazione strategica con sottodomini ", spiega i
sottodomini e come è possibile utilizzarli per gestire la complessità dell'integrazione con i sistemi
legacy esistenti durante la modellazione delle nuove applicazioni. Capitolo 4 ,"Progettazione strategica con mappatura
della contesto", insegna la varietà di modi in cui i team lavorano insieme in modo strategico e i
modi in cui il loro software può integrare. Questo è chiamato mappatura del contesto.
Capitolo 5 , "Progettazione tattica con aggregati", sposta la vostra attenzione sulla
modellazione tattica con gli aggregati. Uno strumento di modellazione tattica importante e potente da
utilizzare con Aggregati è Eventi di dominio , che è oggetto della Capitolo 6 , "Progettazione tattica
con eventi di dominio."
Infine, nel capitolo 7 , "Strumentidiaccelerazione e gestione ", il libro mette in evidenza alcuni strumenti di
accelerazione e gestione dei progetti che possono aiutare i team a stabilire e mantenere la loro cadenza. Questi due argomenti
sono raramente se mai discussi in altre fonti DDD e sono estremamente necessari per coloro che
sono determinati a mettere in pratica DDD.

Convenzioni
Ci sono solo poche convenzioni da tenere a mente durante la lettura. Tutti gli strumenti DDD di cui
discuto sono stampati in corsivo. Ad esempio, si leggerà su Contesti delimitati ed Eventi di Dominio.
Un'altra convenzione è che qualsiasi codice sorgente viene presentato in un tipo di carattere
Courier monospazio. Gli acronimi e le abbreviazioni per le opere elencate nei Riferimenti a pagine
136 -137 appaiono tra parentesi quadre in tutti i capitoli.
Anche così, ciò che questo libro sottolinea di più, e ciò che il vostro cervello dovrebbe piacere
molto, è l'apprendimento visivo attraverso un sacco di diagrammi e figure. Noterete che non ci
sono numeri di cifre nel libro, perché non volevo distrarti con così tanti di questi. In ogni caso le
figure e i diagrammi precedono il testo che li discute, il che significa che le immagini grafiche
introducono pensieri mentre ti fai strada attraverso il libro. Ciò significa che quando si legge il
testo, è possibile contare sul riferimento alla figura o al diagramma precedente per il supporto
visivo.
Riconoscimenti

Questo è ora il mio terzo libro all'interno della prestigiosa etichetta Addison-Wesley. E 'anche la
mia terza volta a lavorare con il mio editore, Chris Guzikowski, e redattore dello sviluppo, Chris , e
sono felice di dire che la terza volta è stata tanto un fascino come i primi due. Grazie ancora per
aver scelto di pubblicare i miei libri.
Come sempre, un libro non può essere scritto e pubblicato con successo senza feedback critici.
Questa volta mi sono rivolto a un certo numero di professionisti DDD che non necessariamente
insegnano o scrivono su di esso, ma stanno comunque lavorando su progetti mentre aiutare gli
altri a utilizzare la potente casella degli strumenti. Sentivo che questo tipo di praticante era
fondamentale per assicurarsi che questo materiale aggressivamente distillato dicesse
esattamente ciò che è necessario e nel modo giusto. È un po' come, se vuoi che parli per 60
minuti, dammi 5 minuti per prepararmi; se vuoi che parli per 5 minuti, dammi qualche ora per
prepararmi.
In ordine per cogiuria, quelli che mi ha ha certo di sono sono stati Jérémie Chassaing, Brian
Dunlap, Yuji Kiriki, Tom Stockton, Tormod J. Varugvik, Daniel Westheide e Philip Windley. Grazie
mille!
Informazioni sull'autore

Vaughn Vernon è un esperto di software e leader di pensiero nella semplificazione della

progettazione e dell'implementazione del software. È autore dei libri più venduti Implementazione
della progettazione basata su dominioImplementing Domain-Driven Design E Modelli di
messaggistica reattiva con il modello attore, anch'essi pubblicati da Addison-Wesley. Ha insegnato il
suo IDDD Workshop in tutto il mondo a centinaia di sviluppatori di software. Vaughn è un oratore
frequente a conferenze di settore. È più interessato all'informatica distribuita, alla messaggistica e in
particolare al modello Actor. Vaughn è specializzata nella consulenza in base al Domain-Driven Design
e
DDD utilizzando il modello Actor con Scala e Akka. Puoi stare al passo con l'ultimo lavoro di
Vaughn leggendo il suo blog allwww.VaughnVernon.co e seguendolo sul suo account Twitter
@VaughnVernon.
Capitolo 1. DDD per me

Vuoi migliorare il tuo mestiere e aumentare il tuo successo sui progetti. Siete ansiosi di aiutare il
vostro business a competere a nuove altezze utilizzando il software che si crea. Si desidera
implementare un software che non solo modelli correttamente le esigenze aziendali, ma funzioni
anche su larga scala utilizzando le architetture software più avanzate. Imparare la progettazione
basata il tuo dominio (DDD) e impararla rapidamente, può aiutare a raggiungere tutto questo e altro
ancora.
DDD è un insieme di strumenti che ti aiutano nella progettazione e implementazione di
software che offre un valore elevato, sia strategicamente che tatticamente. La tua organizzazione
non può essere la migliore in tutto, quindi è meglio scegliere con attenzione a ciò che deve
eccellere. Gli strumenti di sviluppo strategico DDD aiutano te e il tuo team a prendere le migliori
scelte di progettazione del software e decisioni di integrazione per la tua azienda. L'organizzazione
trarrà i maggiori vantaggi dai modelli software che riflettono in modo esplicito le proprie
competenze principali. Gli strumenti di sviluppo tattico DDD possono aiutare te e il tuo team a
progettare un software utile che modella accuratamente le operazioni uniche dell'azienda.
L'organizzazione deve trarre vantaggio dalle ampie opzioni per distribuire le soluzioni in una
varietà di infrastrutture, sia in casa che nel cloud. Con DDD, tu e il tuo team potete essere voi a
realizzare le progettazioni e le implementazioni software più efficaci necessarie per avere successo
nel panorama aziendale competitivo di oggi.
In questo libro ho distillato DDD per voi, con un trattamento condensato degli strumenti di
modellazione strategica e tattica. Comprendo le esigenze uniche dello sviluppo del software e le
sfide che dovete affrontare mentre lavorate per migliorare il vostro mestiere in un settore frenetico.
Non si può sempre prendere mesi per leggere su un argomento come DDD, eppure si vuole ancora
mettere DDD a lavorare il più presto possibile.
Sono autore del libro best-seller Implementing Domain-Driven Design [IDDD] , e ho anche
creato e insegnato il workshop IDDD di tre giorni. E ora ho anche scritto questo libro per portarvi
DDD in una forma aggressivamente condensata. Fa tutto parte del mio impegno a portare DDD in
ogni team di sviluppo software, dove merita di essere. Il mio obiettivo, ovviamente, include
portare DDD a voi.
DDD farà male?
Potresti aver sentito che DDD è un approccio complicato allo sviluppo del software. Complicato?
Certamente non è complicato di necessità. In effetti, è un insieme di tecniche avanzate da
utilizzare su progetti software complessi. Grazie al suo potere e quanto devi imparare, senza
istruzioni di esperti può essere scoraggiante mettere DDD in pratica da solo. Probabilmente avete
anche scoperto che alcuni degli altri libri DDD sono molte centinaia di pagine lunghe e tutt'altro
che facili da consumare e applicare. Mi ha richiesto un sacco di parole per spiegare DDD in
dettaglio al fine di fornire un riferimento di implementazione esaustiva su più di una dozzina di
argomenti e strumenti DDD. Tale sforzo ha portato all'implementazione di progettazione basata
su dominio [IDDD] . Questo nuovo libro condensato è fornito per familiarizzare con le parti più
importanti di DDD nel modo più rapido e semplice possibile. Perché? Perché alcuni sono
sopraffatti dai testi più grandi e hanno bisogno di una guida distillata per aiutarli a fare i primi passi
per l'adozione. Ho scoperto che coloro che usano DDD rivisitano la letteratura su di esso più volte.
Infatti, si potrebbe anche concludere che non si potrà mai imparare abbastanza, e così si utilizzerà
questo libro come riferimento rapido, e fare riferimento ad altri per ulteriori dettagli, un certo
numero di volte come il vostro mestiere è raffinato. Altri hanno avuto problemi a vendere DDD ai
loro colleghi e all'importantissimo team di gestione. Questo libro ti aiuterà a farlo, non solo
spiegando DDD in un formato condensato, ma anche mostrando che gli strumenti sono disponibili
per accelerarne e gestire il suo utilizzo.
Naturalmente, non è possibile insegnarti tutto su DDD in questo libro, perché ho volutamente
distillato le tecniche DDD per te. Per una copertura molto più approfondita, vedere il mio libro
Implementazione della progettazione basata su dominioImplementing Domain-Driven Design [IDDD]
e cercare di prendere il mio officina IDDD di tre giorni. Il corso intensivo di tre giorni, che ho distribuito in tutto il
mondo a un vasto pubblico di centinaia di sviluppatori, ti aiuta a raggiungere rapidamente DDD.
Fornisco anche formazione DDD
Online allhttp://ForComprehension.com .
La buona notizia è che la DDD non deve far male. Dal momento che probabilmente hai già a
che fare con la complessità dei tuoi progetti, puoi imparare a usare DDD per ridurre il dolore di
vincere la complessità.

Design buono, cattivo ed efficace

Spesso la gente parla di buon design e cattivo design. Che tipo di design fai? Molti team di
sviluppo software non danno design nemmeno un pensiero passeggeri. Invece, eseguono quello
che io chiamo "il task-board shuffle". Questo è dove il team ha un elenco di attività di sviluppo,
ad esempio con un backlog del prodotto Scrum, e spostano una nota adesiva dalla colonna "Da
fare" della scheda alla colonna "In corso". L'esecuzione dell'oggetto backlog e l'esecuzione del
"shuffle della scheda attività" costituiscono la totalità di intuizioni premurose, e il resto è lasciato
alla codifica eroica mentre i programmatori esplodono la fonte. Raramente si scopre così come
potrebbe, e il costo per l'azienda è di solito il prezzo più alto pagato per tali disegni inesistenti.
Ciò accade spesso a causa della pressione di fornire rilasci software in un programma
inesorabile, in cui la gestione utilizza Scrum principalmente per controllare le tempistiche
piuttosto che consentire uno dei principi più importanti di Scrum: l'acquisizione della conoscenza.
Quando consulto o insegno presso le singole imprese, generalmente trovo le stesse situazioni.
Software
sono in pericolo, e interi team vengono assunti per mantenere i sistemi operativi, il codice di
patch e
dati giornalieri. Di seguito sono riportati alcuni dei problemi insidiosi che trovo, e interessante
quelli che
DDD può facilmente aiutare i team a evitare. Comincio con i problemi aziendali di livello
superiore e passo a quelli più tecnici:
• Lo sviluppo di software è considerato un centro di costo piuttosto che un centro di profitto.
Generalmente questo è perché l'azienda vede i computer e il software come disturbi
necessari piuttosto che fonti di vantaggio strategico. (Purtroppo non ci può essere una cura
per questo se la cultura aziendale è saldamente fissato.)
• Gli sviluppatori sono troppo dotati di tecnologia e cercando di risolvere i problemi
utilizzando la tecnologia, piuttosto che un'attenta riflessione e progettazione. Questo porta
gli sviluppatori a inseguire costantemente nuovi "oggetti brillanti", che sono le ultime mode
della tecnologia.
• Al database viene assegnata troppa priorità e la maggior parte delle discussioni sul database
delle soluzioni e su un modello di dati anziché sui processi e le operazioni aziendali.
• Gli sviluppatori non danno la giusta enfasi alla denominazione di oggetti e operazioni in
base allo scopo aziendale che riempiono. Questo porta ad un grande abisso tra il modello
mentale che l'azienda possiede e il software che gli sviluppatori forniscono.
• Il problema precedente è generalmente il risultato di una scarsa collaborazione con
l'azienda. Spesso le parti interessate aziendali dedicano troppo tempo al lavoro isolato
 producendo specifiche che nessuno utilizza o che sono consumate solo in parte dagli
sviluppatori.
• Le stime del progetto sono molto richieste e molto spesso produrle può aggiungere tempo e
fatica significativi, con conseguente ritardo dei risultati finali del software. Gli sviluppatori
utilizzano il "task-board shuffle" piuttosto che un design premuroso. Producono una Grande
Palla di Fango (discussa nei capitoli seguenti) piuttosto che separare adeguatamente i modelli in
base ai driver di business.
• Gli sviluppatori ospitano la logica di business nei componenti dell'interfaccia utente e nei
componenti di persistenza. Inoltre, gli sviluppatori spesso eseguono operazioni di
persistenza nel mezzo della logica di business.
 • Sono presenti query di database interrotte, lente e bloccate che impediscono agli utenti
di eseguire operazioni aziendali sensibili al tempo.
• Ci sono astrazioni errate, in cui gli sviluppatori tentano di soddisfare tutte le esigenze
future attuali e immaginarie generalizzando eccessivamente le soluzioni piuttosto che
soddisfare le reali esigenze aziendali concrete.
• Esistono servizi fortemente accoppiati, in cui viene eseguita un'operazione in un servizio e
tale servizio chiama direttamente a un altro servizio per causare un'operazione di
bilanciamento. Questo accoppiamento spesso porta a processi aziendali rotti e dati non
riconciliati, per non parlare dei sistemi che sono molto difficili da mantenere.
Tutto questo sembra accadere nello spirito di "nessun design produce software a basso costo."
E troppo spesso è semplicemente una questione di aziende e gli sviluppatori di software non
sapendo che c'è un'alternativa molto migliore. "Il software sta mangiando il mondo" [WSJ] , e
dovrebbe essere importante per voi che il software può anche mangiare i vostri profitti, o alimentare i vostri
profitti un banchetto.
È importante capire che l'economia immaginata di No Design è un errore che ha abilmente
ingannato coloro che applicano la pressione per produrre software senza design premuroso.
Questo perché la progettazione scorre ancora dal cervello dei singoli sviluppatori attraverso la
punta delle dita mentre wrangle con il codice, senza alcun input da altri, tra cui l'azienda. Penso
che questa citazione riassume bene la situazione:
Domande sul fatto che il design sia necessario o conveniente sono abbastanza al di là del
punto: il design è inevitabile. L'alternativa al buon design è il cattivo design, non nessun
design a tutti.
-Progettazione di libri: un'introduzione pratica di Douglas Martin

Anche se i commenti di Mr. Martin non riguardano specificamente la progettazione del

software, sono ancora applicabili al nostro mestiere, dove non esiste un sostituto per il design
premuroso. Nella situazione appena descritta, se si dispone di cinque sviluppatori di software
che lavorano al progetto, No Design produrrà effettivamente una fusione di cinque diversi
disegni in uno. Cioè, si ottiene una miscela di cinque diverse interpretazioni di linguaggio di
business made-up che vengono sviluppati senza il beneficio dei veri esperti di Dominio.
La linea di fondo: modelliamo se riconosciamo la modellazione o no. Questo può essere
paragonato a come si sviluppano le strade. Alcune antiche strade iniziarono come sentieri per carri
che alla fine furono modellati in sentieri ben indossati. Hanno preso turni inspiegabili e fatto
forchette che servivano solo pochi che avevano necessità rudimentali. Ad un certo punto questi
percorsi sono stati levigati e poi pavimentati per il comfort del crescente numero di viaggiatori che li
hanno utilizzati. Queste strade di fortuna non sono percorse oggi perché erano ben progettate, ma
perché esistono. Pochi dei nostri contemporanei possono capire perché viaggiare uno di questi è
così scomodo e scomodo. Le strade moderne sono progettate e progettate secondo studi accurati
sulla popolazione, sull'ambiente e sul flusso prevedibile. Entrambi i tipi di strade sono modellati. Un
modello impiegava un intelletto di base minimo. L'altro modello sfruttava la massima cognizione. Il
software può essere modellato da entrambe le prospettive.
 Se hai paura che la produzione di software con un design premuroso sia costosa, pensa a
quanto più costoso sarà di vivere con o addirittura di riparare un cattivo design. Ciò è
particolarmente simile quando si parla di software che deve distinguere la tua organizzazione da
tutte le altre e produrre notevoli vantaggi competitivi.
Una parola strettamente legata al bene è Efficace , e forse più accuratamente afferma ciò che
dovremmo
 si sforzano nella progettazione del software: una progettazione efficace. Una progettazione
efficace soddisfa le esigenze dell'organizzazione aziendale nella misura in cui può distinguersi
dalla concorrenza attraverso il software. Una progettazione efficace obbliga l'organizzazione
a capire in cosa deve eccellere e viene utilizzata per guidare la creazione del modello
software corretto.
In Scrum, l'acquisizione della conoscenza avviene attraverso la sperimentazione e l'apprendimento
collaborativo ed è indicata come "acquisto di informazioni" [Scrum essenziale] . La conoscenza non è
mai gratuita, ma in questo libro vi fornisco dei modi per accelerare il modo in cui venite da essa.
Nel caso in cui si dubita ancora che il design efficace conta, non dimenticare le intuizioni di
qualcuno che sembra aver capito la sua importanza:
La maggior parte delle persone commettono l'errore di pensare design è quello che sembra.
La gente pensa che sia questa impiallacciatura, che i designer abbiano consegnato questa
scatola e dicano: "Fallo sembrare buono!" Non è quello che pensiamo che il design sia. Non è
solo quello che sembra e ci si sente come. Il design è come funziona.
Offerte di lavoro
per Steve

Nel software, la progettazione efficace è importante, la maggior parte. Data l'unica

alternativa, vi consiglio un design efficace.

Progettazione strategica
Iniziamo con l'importantissimo design strategico. Non è davvero possibile applicare il design tattico in
modo efficace a meno che non si inizia con la progettazione strategica. La progettazione strategica
viene utilizzata come ampie pennellate prima di entrare nei dettagli dell'implementazione. Mette in
evidenza ciò che è strategicamente importante per la tua attività, come dividere il lavoro per
importanza e come integrarlo al meglio in base alle esigenze.
In primo luogo si apprenderà come separare i modelli di dominio utilizzando il modello di
progettazione strategica denominato contesti delimitati. Mano nel guanto, si vedrà come
sviluppare un linguaggio onnipresente come il modello di dominio all'interno di un contesto esplicitamente
delimitato.
 Imparerai l'importanza di interagire non solo con gli sviluppatori, ma anche con gli esperti di
Dominio mentre sviluppi il linguaggio onnipresente del tuo modello. Vedrete come un team di
sviluppatori di Software e dominio Esperti collaborano. Si tratta di una combinazione vitale di
persone intelligenti e motivate che sono necessari per DDD per produrre i migliori risultati. Il
linguaggio che sviluppi insieme attraverso la collaborazione diventerà onnipresente, pervasivo,
in tutto il modello di comunicazione e software parlato del team.
 Man mano che avanzi nella progettazione strategica, imparerai a conoscere i sottodomini e
come questi possono aiutarti a gestire la complessità illimitata dei sistemi legacy e come
migliorare i tuoi risultati sui progetti greenfield. Si vedrà anche come integrare più contesti
delimitati utilizzando una tecnica denominata context mapping. Le mappe di contesto definiscono
sia le relazioni tra team che i meccanismi tecnici esistenti tra due contesti delimitati di integrazione.

Progettazione tattica
Dopo che ti ho dato una solida base con design strategico, scoprirai gli strumenti di
progettazione tattica più importanti di DDD. Il design tattico è come usare un pennello sottile
per dipingere i dettagli del tuo modello di dominio. Uno degli strumenti più importanti viene
utilizzato per aggregare entità e oggetti valore insieme in un cluster di dimensioni corrette. È il
modello Aggregazione.
DDD si tratta di modellare il dominio nel modo più esplicito possibile. L'uso degli eventi di
dominio consente di modellare in modo esplicito e di condividere ciò che si è verificato all'interno del
modello con i sistemi che devono essere a conoscenza. Le parti interessate potrebbero essere il
proprio contesto delimitato locale e altri contesti delimitati remoti.
Il processo di apprendimento e la raffinazione delle conoscenze
DDD insegna un modo di pensare per aiutare te e il tuo team a perfezionare le conoscenze
mentre impari a conoscere le competenze principali della tua azienda. Questo processo di
apprendimento è una questione di scoperta attraverso la conversazione di gruppo e la
sperimentazione. Mettendo in discussione lo status quo e sfidando le vostre ipotesi sul vostro
modello di software, imparerete molto, e questa importantissima acquisizione di conoscenze si
diffonderà in tutto il team. Si tratta di un investimento fondamentale per il tuo business e il tuo
team. L'obiettivo dovrebbe essere non solo quello di imparare e perfezionare, ma di imparare e
perfezionare il più rapidamente possibile. Ci sono ulteriori strumenti per aiutare con quegli
obiettivi che possono essere trovati nel capitolo 7 , "Strumentidiaccelerazione e gestione".

Iniziamo!
Anche in una presentazione condensata, c'è molto da imparare su DDD. Quindi iniziamo
con il Capitolo 2 , "Progettazione strategica con contesti delimitati e il linguaggio
onnipresente ".
Capitolo 2. Progettazione strategica con contesti delimitati e
linguaggio onnipresente

Quali sono queste cose chiamate contesti delimitati ? Cos'è la lingua onnipresente? In breve,
DDD riguarda principalmente la modellazione di un linguaggio ubiquitous in un contesto esplicitamente
delimitato. Anche se è vero, probabilmente non era la descrizione più utile che potessi fornire.
Lascia che te lo faccia.

In primo luogo, un contesto delimitato è un limite contestuale semantico. Ciò significa che
all'interno dei limiti ogni componente del modello software ha un significato specifico e fa cose
specifiche. I componenti all'interno di un contesto delimitato sono specifici del contesto e motivati
semanticamente. È abbastanza semplice.
Quando si è appena iniziato nei vostri sforzi di modellazione del software, il vostro contesto
limitato è in qualche modo concettuale. Si potrebbe pensare ad esso come parte del vostro spazio
Problema. Tuttavia, man mano che il modello inizia ad assumere un significato e una chiarezza più profondi, il contesto
delimitato passerà rapidamente allo spazio della soluzione, con il modello software riflesso come codice sorgente del
progetto. (Le spazio del problema e lo spazio della soluzione sono meglio spiegati nella casella.) Tenere
presente che un contesto delimitato è dove viene implementato un modello e si diranno elementi software
separati per ogni contesto delimitato.
 Che cos'è uno spazio problematico e uno spazio di soluzione?
Lo spazio dei problemi è quello in cui si eseguono analisi strategiche di alto livello e
passaggi di progettazione entro i vincoli di un determinato progetto. È possibile
utilizzare diagrammi semplici mentre si discutono i driver di progetto di alto livello e si
notano obiettivi e rischi importanti. In pratica, le mappe di contesto funzionano
molto bene nello spazio dei problemi. Si noti inoltre che i contesti delimitati possono
essere utilizzati nelle discussioni sull'area dei problemi, quando necessario, ma sono
anche strettamente associati allo spazio della soluzione.
Lo spazio della soluzione è dove si implementa effettivamente la soluzione che le
discussioni sullo spazio dei problemi identificano come dominio principale. Quando il
contesto delimitato viene sviluppato come un'iniziativa strategica chiave
dell'organizzazione, viene chiamato il Dominio principale. Sviluppare la soluzione nel
contesto delimitato come codice, sia origine principale che origine di test. Verrà inoltre prodotto
codice nello spazio della soluzione che supporta l'integrazione con altri contesti
delimitati .

Il modello software all'interno del limite di contesto riflette un linguaggio sviluppato dal team
che lavora nel contesto delimitato e viene parlato da ogni membro del team che crea il modello
software che funziona all'interno di quel contesto delimitato. La lingua è chiamata linguaggio
onnipresente perché è parlata sia tra i membri del team che implementata nel modello software.
Pertanto, è necessario che il linguaggio onnipresente sia rigoroso: rigoroso, esatto, rigoroso e
stretto. Nel diagramma, le caselle all'interno del contesto delimitato rappresentano i concetti del
modello, che possono essere implementati come classi. Quando il contesto delimitato viene sviluppato
come un'iniziativa strategica chiave dell'organizzazione, viene chiamato il Dominio principale.
Rispetto a tutto il software utilizzato dall'organizzazione, un Dominio di base è un modello
software che si colloca tra i più importanti, perché è un mezzo per raggiungere la grandezza. Un
dominio principale è stato sviluppato per distinguere l'organizzazione in modo competitivo da tutti gli altri.
Per lo meno si rivolge a una grande linea di business. La tua organizzazione non può eccellere in
tutto e non dovrebbe nemmeno provare. Quindi scegli saggiamente cosa dovrebbe far parte del
tuo Dominio principale e cosa no. Questa è la proposta di valore principale di DDD e si desidera
investire in modo appropriato eseguendo il commit delle risorse migliori in un dominio principale.
 Quando qualcuno del team usa espressioni della lingua onnipresente, tutti i membri del team
comprendono cosa si intende con precisione e vincoli. L'espressione è onnipresente all'interno del
team, così come tutto il linguaggio utilizzato dal team che definisce il modello software in fase di
sviluppo.
Quando si considera la lingua in un modello software, pensare alle varie nazioni che compongono
l'Europa. All'interno di uno dei paesi in questo spazio, la lingua ufficiale di ogni paese è chiara.
All'interno dei confini di queste nazioni, ad esempio Germania, Francia e Italia, le lingue ufficiali sono
certe. Quando superi un confine, la lingua ufficiale cambia. Lo stesso vale per l'Asia, dove il
giapponese è parlato in Giappone, e le lingue parlate in Cina e Corea sono chiaramente diverse
attraverso i confini nazionali. È possibile pensare ai contesti delimitati in modo molto simile, come ai
limiti del linguaggio. Nel caso di DDD, le lingue sono quelle parlate dal team che possiede il modello
software, e una notevole forma scritta del linguaggio è il codice sorgente del modello software.

Contesti delimitati, team e repository di codice sorgente

Deve essere presente un team assegnato per lavorare su un contesto delimitato.
Dovrebbe inoltre essere presente un repository di codice sorgente separato per ogni contesto
delimitato. È possibile che un team possa lavorare su più contesti delimitati , ma più
team non devono lavorare su un singolo contesto delimitato. Separare in modo
pulito il codice sorgente e lo schema del database per ogni contesto delimitato nello stesso
modo in cui si separa il linguaggio Ubiquitous. Mantenere i test di accettazione e gli
unit test insieme al codice sorgente principale.
È particolarmente importante chiarire che un team lavora su un singolo contesto
delimitato. Questo elimina completamente le possibilità di eventuali sorprese
sgradite che sorgono quando un altro team apporta una modifica al codice sorgente.
Il team è proprietario del codice sorgente e del database e definisce le interfacce
ufficiali attraverso le quali deve essere utilizzato il contesto delimitato. È un vantaggio
dell'utilizzo di DDD.
 Nelle lingue umane, la terminologia si evolve nel tempo, e oltre i confini nazionali le stesse
parole o simili assumono sfumature di significato. Pensate alle differenze tra le parole spagnole
utilizzate in Spagna e quelle stesse parole utilizzate in Colombia, dove cambia anche la pronuncia.
C'è chiaramente lo spagnolo spagnolo e lo spagnolo della Colombia. Così anche con i linguaggi del
modello software. È possibile che le persone di altri team abbiano un significato diverso per la
stessa terminologia, perché le loro conoscenze aziendali sono all'interno di un contesto diverso;
stanno sviluppando un contesto delimitato diverso. Non è previsto che i componenti al di fuori del
contesto aderiscano alle stesse definizioni. In realtà, sono probabilmente diversi, leggermente o in
grande, dai componenti che il team modella. Non c'è problema.

Per comprendere un grande motivo per utilizzare contesti delimitati, consideriamo un

problema comune con i progetti software. Spesso i team non sanno quando smettere di
accumulare sempre più concetti nei propri modelli di dominio. Il modello può iniziare piccolo e
gestibile . . .
 Ma poi il team aggiunge più concetti, e altro ancora, e ancora di più. Questo si traduce presto in un
grosso problema. Non solo ci sono troppi concetti, ma il linguaggio del modello diventa sfocato,
perché quando ci pensi ci sono in realtà più lingue in un unico grande, confuso, modello senza limiti.

A causa di questo errore, i team spesso trasformeranno un prodotto software nuovo di zecca in
quello che viene chiamato un Grande palla di fango. A dire il vero, un Grande Ballo di Fango non è
qualcosa di cui andare fieri. È un monolite, e peggio. Questo è dove un sistema ha più modelli
aggrovigliati senza confini espliciti. Probabilmente richiede anche più team di lavorare su di esso,
che è molto problematico. Inoltre, vari concetti non correlati vengono fatti saltare in aria su molti
moduli e interconnessi con elementi contrastanti. Se questo progetto ha test, probabilmente ci
vuole molto tempo per eseguirli, e quindi i test possono essere bypassati in momenti
particolarmente importanti.
È il prodotto di cercare di fare troppo, con troppe persone, nel posto sbagliato. Qualsiasi
tentativo di sviluppare e parlare un linguaggio onnipresente si tradurrà in un dialetto fratturato e
mal definito che sarà presto abbandonato. La lingua non sarebbe nemmeno così concepita come
l'esperanto. È solo un casino, come una grande palla di fango.
Esperti di dominio e driver di business
Ci possono essere forti, o almeno sottili, suggerimenti comunicati dagli stakeholder aziendali che
avrebbero potuto essere utilizzati per aiutare il team tecnico a fare scelte di modellazione
migliori. Così, un Grande palla di fango è spesso il risultato di uno sforzo sfrenato fatto da un team di
sviluppatori di software che non ascoltano gli esperti di business.

Le divisioni del reparto o del gruppo di lavoro dell'azienda possono fornire una buona indicazione
di dove devono esistere i limiti del modello. Si tende a trovare almeno un esperto di business per
funzione aziendale. Ultimamente c'è una tendenza verso il raggruppamento delle persone per
progetto, mentre le divisioni aziendali o anche i gruppi funzionali sotto una gerarchia di gestione
sembrano essere meno popolari. Anche di fronte a nuovi modelli di business troverete ancora che i
progetti sono organizzati secondo i driver di business e sotto un'area
di competenze. Potrebbe essere necessario pensare a divisione o funzione in questi termini.
È possibile determinare che questo tipo di segregazione è necessario se si considera che ogni
funzione aziendale ha probabilmente definizioni diverse per lo stesso termine. Si consideri il
concetto denominato "politica" e come il significato differisce tra le varie funzioni aziendali
assicurative. Si può facilmente immaginare che una politica nella sottoscrizione sia molto diversa
da una politica delle rivendicazioni e da una politica nelle ispezioni. Vedere la casella per ulteriori
dettagli.
La politica in ciascuna di queste aree di business esiste per diversi motivi. Non c'è modo di
sfuggire a questo fatto, e nessuna quantità di ginnastica mentale cambia questo.

Differenze nei criteri in base alla funzioneDifferences in Policies by Function

Politica nell'underwriting: nel settore delle competenze che si concentra sulla
sottoscrizione, viene creata una politica basata sulla valutazione dei rischi dell'entità
assicurata. Ad esempio, quando lavorano nella sottoscrizione per l'assicurazione
immobiliare, i sottoscrittori valuterebbero i rischi associati a una determinata
proprietà al fine di calcolare il premio per la polizza di copertura dell'attività
immobiliare.
Politica in Ispezioni: Anche in questo caso, se stiamo lavorando nel settore
assicurativo immobiliare, l'organizzazione assicurativa avrà probabilmente un'area di
competenza di ispezione che è responsabile per l'ispezione di un immobile che deve
essere assicurato. I sottoscrittori dipendono in qualche modo dalle informazioni
trovate durante le ispezioni, ma solo dal punto di vista che la proprietà è nella
condizione asserita dall'assicurato. Supponendo che una proprietà sarà assicurata, i
dettagli di ispezione (foto e note) sono associati a una politica nell'area delle ispezioni
e ai suoi dati è possibile fare riferimento sottoscrivendo per negoziare il costo del
premio finale nell'area della sottoscrizione.
Politica nei sinistri: una polizza nel settore dei sinistri di competenza tiene traccia della
richiesta di pagamento della parte dell'assicurato in base ai termini della polizza creata dall'area
della sottoscrizione. La politica dei sinistri dovrà fare alcuni riferimenti alla politica di
sottoscrizione, ma sarà focalizzata, ad esempio, sui danni alla proprietà assicurata e sulle
revisioni eseguite dal personale dei sinistri per determinare il pagamento, se presente,
che dovrebbe essere effettuato.
 Se si tenta di unire tutti e tre questi tipi di criteri in un unico criterio per tutti e tre i gruppi di
business, si avranno sicuramente problemi. Ciò diventerebbe ancora più problematico se il già
politica sovraccarica ha dovuto sostenere un quarto e quinto concetto di business in futuro.
Nessuno vince.

D'altra parte, DDD enfatizza l'adozione di tali differenze separando i diversi tipi in contesti
delimitati diversi. Ammettere che ci sono diverse lingue, e funzionare di conseguenza. Ci sono tre
significati politici? Poi ci sono tre contesti delimitati, ognuno con la propria politica, con ogni
politica che ha le proprie qualità uniche. Non è necessario denominarli UnderwritingPolicy ,
Criteri di reclamo o IspezioniPolitica . Il nome del contesto delimitato si occupa di tale ambito. Il
nome è semplicemente Politica in tutti e tre in contesti delimitati.

Un altro esempio: Cos'è un volo?

Nel settore delle compagnie aeree, un "volo" può avere più significati. C'è un volo che è
definito come un singolo decollo e atterraggio, dove l'aereo è volato da un aeroporto
all'altro. C'è un diverso tipo di volo che è definito in termini di manutenzione degli
aeromobili. E c'è ancora un altro volo che è definito in termini di biglietto passeggeri, sia
senza sosta o one-stop. Poiché ognuno di questi usi di "volo" è chiaramente compreso
solo dal suo contesto, ognuno dovrebbe essere modellato in un contesto delimitato
separato. Modellare tutti e tre questi nello stesso contesto delimitato porterebbe a un
groviglio confuso.
Caso di studio
Per rendere più concreto il motivo dell'utilizzo di contesti delimitati, illustratelo con un modello di dominio
di esempio. In questo caso stiamo lavorando su un'applicazione di gestione dei progetti agile
basata su Scrum. Quindi, un concetto centrale o centrale è Product, che rappresenta il software
che deve essere costruito e che sarà perfezionato nel corso forse anni di sviluppo. Il prodotto
dispone di elementi di backlog, rilasci e sprint. Ogni elemento di backlog ha un numero di attività
e ogni attività può avere una raccolta di voci di log di stima. Le versioni dispongono di elementi di
backlog pianificati e gli sprint dispongono di elementi di backlog vincolati. Fin qui tutto bene.
Abbiamo identificato i concetti di base del nostro modello di dominio e il linguaggio è focalizzato
e intatto.

"Oh, sì", dicono i membri del team, "abbiamo bisogno anche dei nostri utenti. E vogliamo
facilitare le discussioni collaborative all'interno del team del prodotto. Rappresentiamo ogni
organizzazione di sottoscrizione come tenant. All'interno dei tenant sarà consentita la
registrazione di un numero qualsiasi di utenti e gli utenti diranno autorizzazioni. E aggiungiamo
un concetto chiamato Discussione per rappresentare uno degli strumenti di collaborazione che
supporteremo."
 Poi i membri del team aggiungono: "Beh, ci sono anche altri strumenti di collaborazione. Le
discussioni appartengono ai forum e alle discussioni con post. Inoltre vogliamo supportare i
calendari condivisi."

Essi continuano: "E non dimenticate che abbiamo bisogno di un modo per gli inquilini di
effettuare i pagamenti. Venderemo anche piani di supporto a più livelli, quindi abbiamo bisogno
di un modo per monitorare le incidenze. Sia il supporto che i pagamenti devono essere gestiti
con un account."
 E emergono altri concetti: "Ogni Prodotto basato su Scrum ha un team specifico che lavora sul
prodotto. I team sono composti da un singolo Product Owner e da un certo numero di membri
del team. Ma come possiamo affrontare le preoccupazioni relative all'utilizzo delle risorse
umane? Hmmm, cosa succede rebbe se modellassimo le pianificazioni dei membri del team
insieme al loro utilizzo e disponibilità?"
 "Sai cos'altro?" "I calendari condivisi non devono essere limitati alle voci blande del
calendario. Dovremmo essere in grado di identificare tipi specifici di voci di calendario, come
Promemoria, Attività cardine del team, Pianificazione e Riunioni retrospettive e Date di
destinazione."
Aspetta un attimo! Vedi la trappola in cui sta cadendo la squadra? Esaminare la distanza tra i
concetti di base di prodotto, elementi di backlog, rilasci e sprint. La lingua non riguarda più solo
Scrum; è diventato fratturato e confuso.

Non fatevi ingannare dal numero un po 'limitato di concetti denominati. Per ogni elemento
denominato, potremmo aspettarci di avere due o tre concetti in più per supportare quelli che
rapidamente saltato in mente. Il team è già sulla buona strada per la realizzazione di una Grande
Palla di Fango e il progetto è appena iniziato.
Necessaria progettazione strategica fondamentale
Quali strumenti sono disponibili con DDD per aiutarci a evitare tali insidie? Sono necessari almeno
due strumenti di progettazione strategica fondamentali. Uno è il contesto delimitato e l'altro è il
linguaggio onnipresente. L'impiego di un contesto delimitato ci costringe a rispondere alla domanda
"Qual è il nucleo?" Il contesto delimitato dovrebbe tenere da vicino tutti i concetti che sono
fondamentali per l'iniziativa strategica e spingere fuori tutti gli Delimitata altri. I concetti che
rimangono fanno parte del linguaggio onnipresente del team. Vedrete come funziona DDD per
evitare la progettazione di applicazioni monolitiche.

Vantaggi del test

Poiché i contesti delimitati non sono monolitici, altri vantaggi si verificano quando
vengono utilizzati. Uno di questi vantaggi è che i test saranno focalizzati su un modello
e quindi saranno meno numerosi e verranno eseguiti più rapidamente. Anche se
questa non è la motivazione principale per utilizzare contesti delimitati , sicuramente
paga in altri modi.
Letteralmente, alcuni concetti saranno nel contesto e saranno chiaramente inclusi nel linguaggio
del team.
 E altri concetti saranno fuori contesto. I concetti che sopravvivono a questa rigorosa applicazione
del filtro solo core fanno parte del linguaggio onnipresente del team proprietario del contesto
delimitato.

Prendere nota
I concetti che sopravvivono a questa rigorosa applicazione del filtro del contesto
limitato fanno parte del linguaggio onnipresente del team proprietario del contesto
delimitato. Il contorno enfatizza il rigore all'interno.

Quindi, come facciamo a sapere che cosa è il nucleo? È qui che dobbiamo riunire due gruppi
vitali di individui in un unico team collaborativo: esperti di Dominio e sviluppatori di Software.
 Gli esperti di Dominio saranno naturalmente più concentrati sulle preoccupazioni aziendali. I loro pensieri
saranno incentrati sulla loro visione di come funziona l'azienda. Nel campo di Scrum, contare sul fatto
che il Dominio Esperto sia un Scrum Master che capisce a fondo come Scrum viene eseguito su un

progetto.

Proprietario del prodotto o esperto di dominio?

Ci si potrebbe chiedere qual è la differenza tra un proprietario del prodotto Scrum e un
esperto ddd. di dominio. Beh, in alcuni casi potrebbero essere uno e lo stesso, cioè una
persona in grado di ricoprire entrambi i ruoli. Tuttavia, non dovrebbe sorprendere che il
proprietario di un prodotto sia in genere più concentrato sulla gestione e la definizione
delle priorità del backlog del prodotto e sul fatto che la continuità concettuale e tecnica
del progetto sia mantenuta. Questo non significa, tuttavia, che il proprietario del
prodotto è naturalmente un esperto nella competenza principale dell'azienda in cui si sta
lavorando. Assicurati di avere un vero esperto di dominio nel team e non sostituire il proprietario di un
prodotto senza il know-how necessario.

Nella tua attività particolare, hai anche esperti di Dominio. Non è un titolo di lavoro, ma piuttosto
descrive coloro che si concentrano principalmente sul business. È il loro modello mentale con cui
iniziamo a costituire la base del linguaggio onnipresente della squadra.
 D'altra parte, gli sviluppatori sono concentrati sullo sviluppo di software. Come illustrato di
seguito, gli sviluppatori possono essere utilizzati da linguaggi di programmazione e tecnologie.
Tuttavia, gli sviluppatori che lavorano in un
DDD il progetto deve resistere con attenzione alla tentazione di essere così centrati
tecnicamente da non poter accettare il focus aziendale dell'iniziativa strategica di base. Piuttosto,
gli sviluppatori dovrebbero rifiutare qualsiasi non giustificata concisione ed essere in grado di
abbracciare il linguaggio onnipresente che viene gradualmente sviluppato dal team all'interno del
loro particolare contesto delimitato.

Focus sulla complessità aziendale, non sulla complessità tecnica

Si utilizza DDD perché la complessità del modello di business è elevata. Non vogliamo
mai rendere il modello di dominio più complesso di quanto dovrebbe essere. Tuttavia,
si utilizza DDD perché il modello di business è più complesso rispetto agli aspetti
tecnici del progetto. Ecco perché gli sviluppatori devono scavare nel modello di
business con dominio Esperti !
 Sia gli sviluppatori che gli esperti di dominio dovrebbero rifiutare qualsiasi tendenza a consentire
ai documenti di governare sulla conversazione. Il miglior linguaggio onnipresente sarà sviluppato da un
ciclo di feedback collaborativo che scaccia il modello mentale combinato del team. Conversazione
aperta, esplorazione e sfide alla base di conoscenza corrente portano a approfondimenti sul
dominio principale.

Sfida e Unify
Ora torniamo alla domanda "Che cosa è fondamentale?" Utilizzando il modello
precedentemente fuori controllo e in continua espansione, mettiamo in discussione e
unifichiamo!
 Una sfida molto semplice è chiedersi se ognuno dei concetti di grande modello aderisca al
linguaggio onnipresente di Scrum. Beh, lo fanno? Ad esempio, Inquilino , Utente e Autorizzazione
non hanno nulla a che fare con Scrum. Questi concetti devono essere presi in considerazione dal nostro
modello software Scrum.
 Inquilino , Utente e Autorizzazione devono essere sostituiti da Team , ProductOwner (Proprietario
del prodotto) e Membro del team . Un ProductOwner (Proprietario del prodotto) e un Membro
del team sono in realtà utenti in una Locazione , ma Con ProductOwner (Proprietario del
prodotto) e Membro del team aderiamo alla lingua onnipresente di Scrum. Sono naturalmente i
termini che usiamo quando abbiamo conversazioni sui prodotti Scrum e sul lavoro che un team fa con
loro.

SupportPlans E Pagamenti fa davvero parte della gestione dei progetti Scrum? La risposta qui è
chiaramente "no". È vero, sia SupportPlans che Pagamenti saranno gestiti con un Account
Inquilino ma questi non fanno parte del nostro linguaggio Scrum principale. Sono fuori contesto e
vengono rimossi da questo modello.
 Che dire dell'introduzione dei problemi relativi all'utilizzo delle risorse umane? È probabilmente
utile per qualcuno, ma non sta per essere utilizzato direttamente da Volontari TeamMember che
lavorerà su BacklogItemTasks . È fuori contesto.

Dopo l'aggiunta di Team , ProductOwner (Proprietario del prodotto) e Membro del team , i
modellatori hanno realizzato
che mancava un concetto di base per consentire ai membri del team di lavorare sulle attività . In
Scrum si tratta di
noto come Volontario . Quindi, il concetto di Volontario è nel contesto ed è stato incluso nel
linguaggio del modello di base.

Anche se le attività cardine basate sul calendario , Le retrospettive e simili sono nel contesto, il team
preferirebbe salvare gli sforzi di modellazione per uno sprint successivo. Sono nel contesto, ma
per ora sono fuori portata.

Infine, i modellatori vogliono assicurarsi di tenere conto del fatto che le discussioni in filo faranno
parte del modello principale. Così modellano una discussione . Ciò significa che Discussione fa
parte del linguaggio onnipresente del team e quindi all'interno del contesto delimitato.
 Queste sfide linguistiche hanno portato a un modello molto più pulito e chiaro della lingua
Onnipresente. Ma in che modo il modello Scrum soddisferà le discussioni necessarie? Sarebbe
certamente necessario un sacco di supporto di componenti software acillary per farlo
funzionare, quindi sembra inappropriato modellarlo all'interno del nostro contesto limitato
Scrum. Contesto delimitato. Infatti, la suite di collaborazione completa è fuori contesto. La
discussione sarà supportata dall'integrazione con un altro contesto delimitato, ovvero il contesto di
collaborazione.

Dopo questa procedura, ci rimane un dominio principale effettivo molto più piccolo.
Naturalmente il Dominio di base crescerà. Sappiamo già che la pianificazione, le retrospettive,
Le attività cardine e i relativi modelli basati sul calendario devono essere sviluppati nel tempo.
Tuttavia, il modello crescerà solo man mano che nuovi concetti aderiscono al linguaggio
onnipresente di Scrum.
 E per quanto riguarda tutti gli altri concetti di modellazione che sono stati rimossi dal
dominio di base ? E 'del tutto possibile che molti degli altri concetti, se non tutti, saranno
composti nei propri rispettivi contesti delimitati , ciascuno aderendo al proprio linguaggio
onnipresente. In seguito si vedrà come ci integriamo con loro utilizzando Mapping del contesto.

Sviluppare un linguaggio onnipresente

Quindi, come si fa a sviluppare un linguaggio onnipresente all'interno del vostro team come si
mette in pratica uno degli strumenti principali forniti da DDD? Il tuo linguaggio onnipresente è
formato da una serie di sostantivi ben noti? I sostantivi sono importanti, ma spesso gli
sviluppatori di software mettono troppa enfasi sui sostantivi all'interno di un modello di dominio,
dimenticando che la lingua parlata è composta da molto più di sostantivi da soli. È vero, ci siamo
concentrati principalmente sui sostantivi all'interno del nostro campione precedente Contesti delimitati fino
a questo punto, ma questo perché eravamo interessati a un altro aspetto di DDD, quello di
vincolare un nucleo Dominio di base verso il basso per gli elementi essenziali del modello.

Accelera la tua scoperta

Puoi provare alcune sessioni di Storming di eventi mentre lavori sui tuoi scenari.
Questi possono aiutare a capire rapidamente quali scenari si dovrebbe lavorare su e
come devono essere prioritizzati. Allo stesso modo, lo sviluppo di scenari concreti ti
darà un'idea migliore della direzione che dovresti prendere nelle tue sessioni di Event
 Storming. Sono due strumenti che funzionano bene insieme. Spiego l'uso di
Storming di eventi nel capitolo 7 , "Strumentidi accelerazione e gestione".

Non limitare il tuo dominio principale ai sostantivi da solo. Piuttosto, si consiglia di esprimere il
Dominio di base come un set di scenari concreti sulle operazioni che il modello di dominio deve eseguire. Quando dico
"scenari" non intendo casi d'uso o storie utente, come è comune nei progetti software. Voglio
dire letteralmente in termini di funzionamento del modello di dominio, ovvero le operazioni
eseguite dai vari componenti. Questo può essere realizzato nel modo più approfondito solo
collaborando come un team di esperti di Dominio e sviluppatori.
Ecco un esempio di uno scenario che si adatta alla lingua onnipresente di Scrum:

Consentire il commit di ogni elemento di backlog in uno sprint. È possibile eseguire il

commit dell'elemento di backlog solo se è già pianificato per il rilascio. Se è già stato
eseguito il commit in uno sprint diverso, è necessario prima di non eseguire il commit. Al
termine del commit, informare le parti interessate.
Si noti che questo non è solo uno scenario su come gli esseri umani utilizzano Scrum su un
progetto. Non stiamo parlando di procedure umane. Piuttosto, questo scenario è una
descrizione di come i componenti del modello software molto reali vengono utilizzati per
supportare la gestione di un progetto basato su Scrum.
Lo scenario precedente non è perfettamente indicato, e un vantaggio di utilizzare DDD è che
siamo costantemente alla ricerca di modi per migliorare il modello. Eppure questo è un inizio
decente. Sentiamo parlare i sostantivi, ma il nostro scenario non ci limita ai sostantivi. Sentiamo
anche verbi e avverbi e altri tipi di grammatica. Si sente anche che esistono vincoli, condizioni che
devono essere soddisfatte prima che lo scenario possa essere completato fino alla fine. Il
vantaggio più importante e la funzionalità di empowering è che si può effettivamente avere
conversazioni su come funziona il modello di dominio, la sua progettazione.
Possiamo anche disegnare semplici immagini e diagrammi. Si tratta di fare tutto ciò che è
necessario per comunicare bene in squadra. Una parola di avvertimento è appropriata qui.
Prestare attenzione al tempo trascorso negli sforzi di modellazione del dominio quando si tratta
di mantenere i documenti con scenari scritti e disegni e diagrammi aggiornati nel lungo periodo.
Queste cose non sono il modello di dominio. Piuttosto, sono solo strumenti che consentono di
sviluppare un modello di dominio. Alla fine il codice è il modello e il modello è il codice.
Cerimonia è per le osservanze illustri, come matrimoni, non modelli di dominio. Questo non
significa che si rinunciare a qualsiasi sforzo per rinfrescare gli scenari, ma farlo solo fino a quando
è utile piuttosto che gravoso.
Cosa faresti per migliorare una parte della lingua onnipresente nel nostro esempio precedente?
Pensaci solo per un minuto. Cosa manca? In poco tempo probabilmente si desidera una
comprensione di chi esegue il commit di elementi di backlog in uno sprint. Aggiungiamo chi e vediamo cosa
succede:
Il proprietario del prodotto esegue il commit di ogni elemento di backlog in uno sprint. . .
Si noterà in molti casi che è necessario denominare ogni persona coinvolta nello scenario e
assegnare alcuni attributi distintivi ad altri concetti, ad esempio per l'elemento di backlog e
sprint. Questo contribuirà a rendere il vostro scenario più concreto e meno simile a una serie di
dichiarazioni sui criteri di accettazione. Ancora, in questo caso particolare non c'è un motivo
forte per nominare il proprietario del prodotto o descrivere ulteriormente l'elemento di backlog
e sprint coinvolti. In questo caso tutti i proprietari di prodotti, gli elementi di backlog e gli sprint
funzioneranno allo stesso modo, indipendentemente dal fatto che abbiano o meno una persona
o un'identità concreta. Nei casi in cui l'inserimento di nomi o altre identità distintive ai concetti
nello scenario consente di utilizzarli:
Il proprietario del prodotto Isabel esegue il commit dell'elemento Visualizza backlog
profili utente nello sprint dei profili utente di consegna . . .
Ora fermiamoci un attimo. Non è che il proprietario del prodotto sia l'unico individuo
responsabile di decidere che un elemento di backlog verrà impegnato in uno sprint. I team di Scrum
non avrebbero molto paura, perché si sarebbero impegnati a fornire software entro un certo lasso
di tempo che non avevano voce in capitolo nel determinare. Tuttavia, per il nostro modello di
software può essere più pratico per una singola persona avere responsabilità di eseguire questa
particolare azione sul modello. Quindi, in questo caso abbiamo dichiarato che è il ruolo di
proprietario del prodotto che fa questo. Anche così, la natura dei team Scrum costringe la
domanda "C'è qualcosa che deve essere fatto dal resto del team per consentire al proprietario
del prodotto di eseguire l'impegno?"
Vedete cos'è successo? Sfidando il modello attuale con la domanda di chi, siamo stati portati a
un'opportunità per una visione più approfondita del modello. Forse dovremmo richiedere almeno
un certo consenso del team che un elemento di backlog può essere commesso prima di consentire
effettivamente al proprietario del prodotto di eseguire l'operazione di commit. Ciò potrebbe portare
al seguente scenario raffinato:
 Il proprietario del prodotto esegue il commit di un elemento di backlog in uno sprint. È
possibile eseguire il commit dell'elemento di backlog solo se è già pianificato per il
rilascio e se un quorum dei membri del team ha approvato l'impegno. . .
OK, ora abbiamo un linguaggio Ubiquitous raffinato , perché abbiamo identificato un nuovo
concetto di modello chiamato Quorum. Abbiamo deciso che ci deve essere un Quorum di membri del team che
concordano che un elemento di backlog dovrebbe essere impegnato, e ci deve essere un modo per loro di
approvare l'impegno. Questo ha ora introdotto un nuovo concetto di modellazione e qualche idea
che l'interfaccia utente dovrà facilitare queste interazioni del team. Vede l'instaria di
innovazione?
C'è altro che manca dal modello. Quale? Il nostro scenario di apertura si è concluso:

Al termine del commit, informare le parti interessate.

Chi o quali sono le parti interessate? Questa domanda e questa sfida portano
ulteriormente alla modellazione di informazioni dettagliate. Chi deve sapere quando un
elemento di backlog è stato impegnato in uno sprint? In realtà un elemento importante del
modello è lo sprint stesso. Lo sprint deve tenere traccia dell'impegno totale dello sprint e lo
sforzo già necessario per eseguire tutte le attività dello sprint. Tuttavia si decide di progettare
lo sprint per tenere traccia di tale, il punto importante ora è per lo sprint di ricevere una
notifica quando un elemento di backlog viene impegnato in esso:
Se è già stato eseguito il commit in uno sprint diverso, è necessario prima di non
eseguire il commit. Al termine dell'impegno, notificare lo sprint da cui è stato eseguito
in noncommitment e lo sprint che ora risulta committato.
Ora abbiamo uno scenario di dominio abbastanza decente. Questa frase conclusiva ci ha
anche portato a capire che l'elemento di arretrato e lo sprint potrebbero non essere
necessariamente consapevoli dell'impegno allo stesso tempo. Dobbiamo chiedere all'azienda di
essere certi, ma suona come un ottimo posto per introdurre la coerenza finale. Vedrete perché
questo è importante e come si realizza nel Capitolo 5 , "Progettazione tattica con aggregati".
Lo scenario raffinato nella sua interezza si presenta così:

Il proprietario del prodotto esegue il commit di un elemento di backlog in uno sprint. È

possibile eseguire il commit dell'elemento di backlog solo se è già pianificato per il
rilascio e se un quorum dei membri del team ha approvato l'impegno. Se è già stato
eseguito il commit in uno sprint diverso, è necessario prima di non eseguire il commit.
 Al termine dell'impegno, notificare lo sprint da cui è stato eseguito in noncommitment
e lo sprint che ora risulta committato.
In che modo un modello software funzionerebbe in pratica? Si può ben immaginare
un'interfaccia utente molto innovativa che supporta questo modello software. Come team Scrum
sta partecipando a una pianificazione sprint sessione, i membri del team utilizzano i loro
smartphone o altri dispositivi mobili per aggiungere la loro approvazione a ogni elemento di
backlog come viene discusso e concordato di lavorare durante lo sprint successivo. L'accordo
del quorum dei membri del team che approvano ciascuno degli elementi di backlog offre al
proprietario del prodotto la possibilità di eseguire il commit di tutti gli elementi di backlog
approvati nello sprint.

Mettere gli scenari al lavoro

Ci si potrebbe chiedere come è possibile effettuare la transizione da uno scenario scritto a una sorta
di elemento che può essere utilizzato per convalidare il modello di dominio rispetto alle specifiche
del team. Esiste una tecnica denominata Specifica per esempio [Specifica] che può essere utilizzata;
è anche chiamata Sviluppo basato sul comportamento [BDD] . Ciò che si sta cercando di ottenere
con questo approccio è quello di sviluppare e perfezionare in modo collaborativo un linguaggio onnipresente ,
modello con una comprensione condivisa e determinare se il modello aderisce alle specifiche. A tale
scopo, creare test di accettazione. Ecco come potremmo riformulare lo scenario precedente come
una
Fare clic qui per visualizzare l'immagine del codice

Scenario:
The product owner commits a backlog item to a sprint
Given a backlog item that is scheduled for release
And the product owner of the backlog item
And a sprint for commitment
And a quorum of team approval for commitment
When the product owner commits the backlog item to the sprint
Then the backlog item is committed to the sprint
And the backlog item committed event is created

Con uno scenario scritto in questo formato, è possibile creare codice di backup e utilizzare
uno strumento per eseguire questa specifica. Anche senza uno strumento, è possibile che
questa forma di creazione di scenari con l'approccio specificato/when/then funziona meglio
rispetto all'esempio di creazione di scenari precedente. Tuttavia, l'esecuzione delle specifiche
come mezzo per convalidare il modello di dominio potrebbe essere difficile da resistere.
Commento ulteriormente questo nel Capitolo 7 , "Strumentidi accelerazione e gestione ".
Non è necessario usare questa forma di specifica eseguibile per convalidare il modello di
dominio rispetto agli scenari. È possibile usare un framework di unit test per eseguire la stessa
operazione, in cui si creano test di accettazione (non unit test) che convalidano il modello di
dominio:

/*

The product owner commits a backlog item to a sprint. The backlog item may be
committed only if it is already scheduled for release, and if a quorum of team
members have approved commitment. When the commitment completes, notify the sprint
to which it is now committed.
*/

[Test]
public void ShouldCommitBacklogItemToSprint()
{
// Given
var backlogItem = BacklogItemScheduledForRelease();
var productOwner = ProductOwnerOf(backlogItem);
var sprint = SprintForCommitment();
var quorum = QuorumOfTeamApproval(backlogItem, sprint);
// When backlogItem.CommitTo(sprint, productOwner, quorum);
// Then Assert.IsTrue(backlogItem.IsCommitted());
var backlogItemCommitted =
backlogItem.Events.OfType<BacklogItemCommitted>().SingleOrDefault();
Assert.IsNotNull(backlogItemCommitted); }
public void ShouldCommitBacklogItemToSprint()
 Questo approccio basato su unit test per i test di accettazione raggiunge lo stesso obiettivo
della specifica eseguibile. Il vantaggio qui può essere la possibilità di scrivere questo tipo di
convalida dello scenario più rapidamente, ma a costo di una certa leggibilità. Ancora, la maggior
parte degli esperti di dominio dovrebbe essere in grado di seguire questo codice con l'aiuto dello sviluppatore.
Quando si utilizza questo approccio sarebbe probabilmente funzionare meglio per mantenere il
modulo di documento dello scenario associato al codice di convalida nei commenti, come
illustrato in questo esempio.
Qualunque sia l'approccio che si decide, entrambi verranno in genere utilizzati in modo rosso-
verde (fail-pass), in cui la specifica avrà prima esito negativo quando viene eseguita, perché non
esiste alcuna implementazione dei concetti del modello di dominio ancora da convalidare. È
possibile perfezionare il modello di dominio passo a passo con una serie di risultati rossi fino a
quando non si supporta completamente la specifica e le convalide passano (viene visualizzato
tutto verde). Questi test di accettazione verranno associati direttamente al contesto delimitato e
mantenuti nel relativo repository del codice sorgente.

E il Long Haul?
Ora vi starete chiedendo come dovremmo sostenere il linguaggio onnipresente una volta che
l'innovazione è cessata e la manutenzione imposta in. In realtà, alcuni dei migliori
apprendimento, o acquisizione di conoscenze, avviene per un lungo periodo di tempo, anche
durante quello che alcuni potrebbero riferirsi a come "manutenzione". È un errore per i team
ritenere che l'innovazione finisca all'inizio della manutenzione.
Forse la cosa peggiore che potrebbe accadere è che l'etichetta "fase di manutenzione" da
collegare a un dominio di base. Un processo di apprendimento continuo non è affatto una fase. Il
linguaggio onnipresente che è stato sviluppato all'inizio deve continuare a prosperare con il passare
degli anni. È vero, alla fine può essere meno significativo, ma probabilmente non per un bel po '.
Fa tutto parte dell'impegno della tua organizzazione per un'iniziativa di base. Se questo impegno
a lungo termine non può essere preso, questo modello su cui si sta lavorando oggi è veramente
un elemento di differenziazione strategica, un dominio di base?
Architettura
C'è un'altra domanda che forse vi siete chiesti. Cosa c'è all'interno di un contesto delimitato ?
Utilizzando questo diagramma dell'architettura di porte e adattatori [IDDD], è possibile vedere che un
contesto delimitato è composto da più di un modello di dominio.

Questi livelli sono comuni in un contesto delimitato: adattatori di input , ad esempio controller
dell'interfaccia utente, endpoint REST e listener di messaggi. Servizi applicativi che orchestrano i casi
d'uso e gestiscono le transazioni, ovvero il modello di dominio su cui ci siamo concentrati; e gli Adattatore di output,
ad esempio la gestione della persistenza e i mittenti dei messaggi. C'è molto da dire sui vari strati di questa
architettura, ed è troppo elaborato per essere affermato in questo libro distillato. Vedere il
capitolo 4 sull'implementazione della progettazione basata il tuo dominio [IDDD] per Un discussione
esaustiva.

Modello di dominio senza tecnologia

Anche se ci sarà tecnologia sparsa in tutta l'architettura, il modello di dominio deve
essere privo di tecnologia. Per prima cosa, ecco perché le transazioni vengono
gestite dai servizi dell'applicazione e non dal modello di dominio.
 Porte e adattatori possono essere utilizzati come architettura di base, ma non è l'unico che
può essere utilizzato insieme a DDD. Insieme a porte e adattatori, è possibile utilizzare DDD con
una qualsiasi di queste architetture o modelli di architettura (e altri), mescolandoli e abbinandoli
in base alle esigenze:
• Architettura basata su eventi; Origine evento [IDDD] . Si noti che Approvvigionamento

eventi è descritto in questo libro nel Capitolo 6 ,"Progettazione tattica con eventi di dominio ".
• Separazione responsabilità query di comando (CQRS)Command Query Responsibility
Segregation (CQRS) [IDDD] .
• Modello reattivo e attore; vedere Modelli di messaggistica reattiva con il modello attore

[Reattivo] , che illustra anche l'utilizzo del modello Attore con DDD.
• Trasferimento di stato rappresentativo (REST) [IDDD] .

• Architettura orientata ai servizi (SOA) [IDDD] .

• I microservizi sono spiegati in Creazione di microserviziBuilding Microservices

[Microservizi] come essenzialmente equivalente a DDD Contesti delimitati , quindi sia il
libro che stai leggendo sia l'implementazione di Progettazione basata su dominio [IDDD]
illustrano lo sviluppo di microservizi da questo punto di vista.
• Il cloud computing è supportato in modo molto simile ai microservizi, in modo che tutto
ciò che si legge in questo libro, in Implementazione della progettazione basata su
dominioImplementing Domain-Driven Design [IDDD] e in Reattiva Modelli di
messaggistica con il modello attore [Reattivo] sia applicabile.
Un altro commento sui microservizi è in ordine. Alcuni considerano un microservizio molto più
piccolo di un contesto delimitato Ddd. Utilizzando tale definizione, un microservizio modella un solo
concetto e gestisce un tipo ristretto di dati. Un esempio di tale microservizio è un prodotto e un altro è
un BacklogItem . Se questa è la granularità che si considera un microservizio degno, tenere presente
che sia il microservizio Prodotto che il microservizio BacklogItem saranno ancora nello stesso contesto delimitato
logico e più grande. I due piccoli componenti di microservizio hanno solo unità di distribuzione diverse,
che possono anche avere un impatto sulla loro interazione (vedere Mapping del contesto ).
Linguisticamente sono ancora all'interno dello stesso limite contestuale e semantico basato su
Scrum.

Riepilogo
In sintesi hai imparato:
• Alcune delle principali insidie di mettere troppo in un modello e creare una grande palla di
fango
• L'applicazione della progettazione strategica DDD
• L'uso del contesto delimitato e della linguaggio onnipresente
• Come sfidare i presupposti e unificare i modelli mentali
 • Come sviluppare un linguaggio onnipresente
• Informazioni sui componenti dell'architettura trovati all'interno di un contesto delimitato
• Che DDD non è troppo difficile da mettere in pratica da soli!
Per un trattamento più approfondito dei contesti delimitati , vedere il capitolo 2 dell'implementazione della
progettazione basata il tuo dominio [IDDD] .
Capitolo 3. Progettazione strategica con sottodomini

Quando si lavora su un progetto DDD, ci sono sempre più contesti delimitati in gioco. Uno dei
contesti delimitati sarà il dominio di Base e ci saranno anche vari sottodomini in altri contesti delimitati. Nel
capitolo precedente si ha visto l'importanza di dividere diversi modelli per il loro specifico linguaggio
onnipresente e formare più contesti delimitati . Nel diagramma precedente sono presenti sei contesti delimitati e sei
sottodomini. Poiché è stata utilizzata la progettazione strategica DDD, i team hanno ottenuto la composizione di
modellazione ottimale: un sottodominio per ogni contesto delimitato e un contesto delimitato per
sottodominio. In altre parole, Nucleo di gestione dei progetti Agile è sia un contesto delimitato pulito che
un sottodominio pulito. In alcune situazioni, possono essere presenti più sottodomini in un contesto
delimitato , ma che non ottiene il risultato di modellazione più ottimale.

Che cos'è un sottodominio?

In poche parole, un sottodominio è una parte secondaria del dominio aziendale complessivo. È
possibile considerare un sottodominio come rappresenta un singolo modello di dominio logico. La maggior
parte dei domini aziendali sono di solito troppo grandi e complessi per ragionare nel suo complesso,
quindi in genere ci preoccupiamo solo dei sottodomini che dobbiamo usare all'interno di un singolo
progetto. I sottodomini possono essere utilizzati per suddividere logicamente l'intero dominio
aziendale in modo da comprendere lo spazio dei problemi in un progetto complesso e di grandi dimensioni.
 Un altro modo di pensare a un sottodominio è che si tratta di una chiara area di competenza,
supponendo che sia responsabile di fornire una soluzione a un'area centrale del tuo business.
Ciò implica che il sottodominio specifico avrà uno o più esperti di Dominio che capiscono molto
bene gli aspetti dell'azienda che un sottodominio specifico Sottodominio facilita. Il
sottodominio ha anche un significato strategico maggiore o minore per la tua azienda.
Se DDD fosse stato utilizzato per svilupparlo, il sottodominio sarebbe stato implementato come
contesto delimitato. Le Esperti di dominio che si specializzano in quella particolare area del
business sarebbe sono stati membri del team che ha sviluppato il Contesto delimitato. Sebbene
l'utilizzo di DDD per sviluppare un Contesto delimitato è la scelta ottimale, a volte possiamo solo
desiderare che era stato il caso.

Tipi di sottodomini
Esistono tre tipi principali di sottodomini all'interno di un progetto:
• Dominio principale: Qui si sta effettuando un investimento strategico in un unico modello di
dominio ben definito, impegnando risorse significative per creare con attenzione il linguaggio
Oniquitous Pollici un contesto limitato esplicito. Questo è molto in alto nell'elenco dei progetti della
tua organizzazione perché lo distinguerà da tutti i concorrenti. Poiché l'organizzazione non può
essere distinta in tutte le sue attività, il Dominio principale delimita il punto in cui deve eccellere.
Raggiungere il livello di apprendimento profondo e comprensione necessario per fare tale
determinazione richiede impegno, collaborazione e sperimentazione. È dove
l'organizzazione deve investire in modo più liberale nel software. Fornisco i mezzi per
accelerare e gestire tali progetti in modo efficiente ed efficace più avanti in questo libro.
• Sottodominio di supporto: si tratta di una situazione di modellazione che richiede uno
sviluppo personalizzato, perché non esiste una soluzione pronta all'uso. Tuttavia, non effettuerai
comunque il tipo di investimento che hai effettuato per il tuo Dominio principale. Si consiglia di
prendere in considerazione l'esternalizzazione di questo tipo di contesto delimitato per
evitare di confutare per qualcosa di strategicamente distinguendo, e quindi investire
pesantemente in esso. Questo è ancora un modello software importante, perché il
Dominio di base non può avere successo senza di esso.
• Sottodominio generico: questo tipo di soluzione può essere disponibile per l'acquisto dallo
scaffale, ma può anche essere esternalizzato o addirittura sviluppato in casa da un team che non
ha il tipo di sviluppatori elite che assegni al tuo Dominio principale o anche un sottodominio
Supporting minore. Prestare attenzione a non confondere un sottodominio generico per un
dominio di Base. Dominio principale. Non si vuole fare quel tipo di investimento qui.
Quando si parla di un progetto in cui DDD è impiegato, molto probabilmente stiamo
discutendo di un nucleo Dominio.

Affrontare la complessità
Alcuni dei limiti del sistema all'interno di un dominio aziendale saranno molto probabilmente
sistemi legacy (continuano ad essere utilizzati perché l’azienda è ad essa legati), ad esempio quelli
creati dall'organizzazione o quelli acquistati tramite licenze software, che possono anche essere
obsoleti. A questo punto potresti non essere in grado di fare molto sul miglioramento di tali
sistemi legacy, ma devi comunque ragionare su di essi quando hanno un impatto sul tuo progetto
Dominio principale. A tale scopo, utilizzare Sottodomini come strumento per discutere lo spazio dei
problemi.
 Purtroppo, ma è vero lo stesso, alcuni sistemi legacy sono così contrari al modo DDD di
progettazione con contesti delimitati che si potrebbe anche fare riferimento a loro come Sistemi
Senza Legacy limiti. Questo perché un tale sistema legacy è quello che ho già definito come un Grande
palla di Fango. In realtà l'unico sistema è pieno di più modelli aggrovigliati che avrebbero dovuto
essere progettati e implementati separatamente, ma sono stati mescolati insieme in un pasticcio
molto complesso e intrecciato.

In altre parole, quando stiamo discutendo di un sistema legacy ci sono probabilmente alcuni, anche
molti, modelli di dominio logici che esistono all'interno di tale sistema legacy. Considerare ognuno di
questi modelli di dominio logico come un sottodominio. Nel diagramma, ogni sottodominio logico nel Grande
palla di fango monolitico legacy non delimitato è contrassegnato da una casella tratteggiata.
Esistono cinque modelli logici o sottodomini.
Trattare i sottodomini logici come tali ci aiuta a affrontare la complessità dei sistemi di grandi
dimensioni. Questo ha molto senso perché ci permette di trattare lo spazio problematico come se
fosse stato sviluppato utilizzando
DDD e molteplici Contesti delimitati.
Il sistema legacy sembra meno monolitico e fangoso se immaginiamo lingue Onnipresente seperate ,
almeno per il gusto di capire come dobbiamo integrarci con esso. Pensare e discutere di tali sistemi
legacy utilizzando Sottodomini ci aiuta a far fronte alle dure realtà di un grande modello impigliato. E come
ragioniamo utilizzando questo strumento, siamo in grado di determinare i sottodomini che sono più
prezioso per l'azienda e necessario per il nostro progetto, e quelli che possono essere relegati a uno
status minore.
Con questo in mente, è anche possibile mostrare il dominio di base che si sta lavorando, o si sta
per lavorare, proprio nello stesso semplice diagramma. Questo ti aiuterà a comprendere le
associazioni e le dipendenze tra i sottodomini. Ma salverò i dettagli di tale discussione per Le
mappatura della contesto.

Quando si usa DDD, un contesto delimitato deve allineare uno a uno (1:1) con un singolo
sottodominio. Ovvero, quando si utilizza DDD, se è presente un contesto delimitato , esiste, come
obiettivo, un modello di sottodominio in tale contesto delimitato. Può non essere sempre possibile o
pratico da raggiungere, ma dove possibile è importante progettare in questo modo. Questo
manterrà i tuoi contesti delimitati puliti e concentrati sull'iniziativa strategica di base.
Se è necessario creare un secondo modello Contesto delimitato (all'interno del Dominio
principale ), è necessario separare il modello secondario dal Dominio principale utilizzando un
Modulo [IDDD] . (Un DDD Modulo è fondamentalmente un pacchetto in Scala e Java, e uno spazio dei
nomi in F e c.) Ciò rende una chiara dichiarazione linguistica che un modello è fondamentale e l'altro
è semplicemente di supporto. Questo particolare uso di separazione di un Sottodominio è uno che si
potrebbe impiegare nel vostro spazio della soluzione.

Riepilogo
In sintesi hai imparato:
• Cosa sono i sottodomini e come vengono utilizzati, sia nello spazio dei problemi che nello spazio
della soluzione
• Differenza tra un dominio di base, un sottodominio di supporto e Un sottodominio generico
• Come si può fare uso di Sottodomini ragionare sull'integrazione con un Grande palla di
Fango sistema legacy
• L'importanza di allineare il contesto delimitato Ddd uno a uno con un singolo sottodominio
• Come separare un modello di sottodominio di supporto dal modello di dominio di base usando
un modulo DDD quando non è pratico separare i due in contesti delimitati diversiHow you
should separatee a Supporting Sottodominio modello dal vostro Dominio principale modello con
un Ddd Modulo quando è impraticabile separare i due in diversi Contesti delimitati

Per una copertura esaustiva Sottodomini Vedere Capitolo 2 Di Implementazione della

progettazione basata su dominioImplementing Domain-Driven Design [IDDD] .
Capitolo 4. Progettazione strategica con mappatura del contesto

Nei capitoli precedenti si è appreso che oltre al Dominio di base sono presenti più contesti delimitati
associati a ogni progetto Delimitata DDD. Tutti i concetti che non appartenevano A contesto di gestione dei progetti

Agile, ovvero il dominio principale, sono stati spostati in uno dei diversi altri contesti delimitati.

Si è inoltre appreso che il dominio di Agile Project Management nucleo dovrebbe integrarsi
con altri contesti delimitati. Tale integrazione è nota in DDD come mapping del contesto. Nella
mappa di contesto precedente è possibile notare che Discussione esiste in entrambi i contesti
delimitati. Tenere presente che ciò è dovuto al fatto che il contesto di collaborazione è l'origine della
discussione e che il contesto di gestione dei progetti Agile è il consumer della discussione .
 Un Mappatura del contesto è evidenziato in questo diagramma dalla linea all'interno della
casella tratteggiata. (La casella tratteggiata non fa parte Mappatura del contesto ma viene
utilizzato solo per evidenziare la linea.) In realtà è questa linea tra i due Contesti delimitati che
rappresenta un Mapping del contesto. In altre parole, la linea indica che i due Contesti
delimitati sono mappati in qualche modo. Ci sarà una certa dinamica inter-team tra i due
Contesti delimitati così come una certa integrazione.

Considerando che in due Contesti delimitati ci sono due Lingue ubiquitous , questa riga rappresenta
la traduzione esistente tra le due lingue. A titolo illustrativo, immaginate che due squadre debbano
lavorare insieme, ma che lavorino oltre i confini nazionali e non parlino la stessa lingua. O le squadre
avrebbero bisogno di un interprete, o una o entrambe le squadre dovrebbero imparare molto sulla
lingua dell'altro. Trovare un interprete sarebbe meno lavoro per entrambi i team, ma potrebbe essere
costoso in vari modi. Ad esempio, immaginate il tempo supplementare necessario a una squadra per
parlare con l'interprete e quindi per l'interprete di trasmettere le dichiarazioni all'altra squadra.
Funziona bene per i primi momenti ma poi diventa ingombrante. Tuttavia, i team potrebbero trovare
questa una soluzione migliore rispetto all'apprendimento e all'adozione di una lingua straniera e al
passaggio costante da una lingua all'altra. E, naturalmente, questo descrive la relazione solo tra due
squadre. E se ci fosse qualche altra squadra coinvolta? Analogamente, esisterebbero gli stessi
compromessi nella traduzione di un Lingua onnipresente in un altro, o in qualche altro modo adattarsi
ad un altro Lingua onnipresente.

Quando si parla di Mappatura del contesto , ciò che è di interesse per noi è che digitare di
relazione inter-squadra e integrazione è rappresentata dalla linea tra due contesti delimitati
qualsiasi. Limiti ben definiti e contratti tra di loro supportano cambiamenti controllati nel
tempo. Esistono diversi tipi di mapping di contesto, sia di team che tecnici, che possono essere
rappresentati dalla linea. In alcuni casi verranno miscelate sia una relazione tra team che un mapping di
integrazione.

Tipi di mapping
Quali relazioni e integrazioni possono essere rappresentate dalla riga Mappatura contesto? Ora le
presento.

Partenariato
Esiste una relazione di partenariato tra due team. Ogni team è responsabile di un contesto
delimitato. Creano una Partenariato per allineare i due team con una serie di obiettivi
dipendenti. Si dice che le due squadre avranno successo o falliranno insieme. Dal momento che
sono così strettamente allineati, si incontreranno frequentemente per sincronizzare gli orari e il
lavoro dipendente, e dovranno utilizzare l'integrazione continua per mantenere le loro
integrazioni in armonia. La sincronizzazione è rappresentata dalla spessa linea di mappatura tra i
due team. La linea spessa indica il livello di impegno richiesto, che è piuttosto alto.
Può essere difficile mantenere una Partenariato a lungo termine, così tanti team che entrano
in una Partenariato possono fare meglio per fissare limiti sul termine della relazione. Il partenariato
dovrebbe durare solo fino a quando fornisce un vantaggio, e dovrebbe essere rimappato a una relazione
diversa quando il vantaggio è superato dal prosciugare l'impegno.

Kernel condiviso
Un kernel condiviso , illustrato a pagina 54 dall'intersezione dei due contesti delimitati , descrive la
relazione tra due (o più) team che condividono un modello piccolo ma comune. I team devono
concordare quali elementi del modello devono condividere. È possibile che solo uno dei team
manterrà il codice, la compilazione e il test per ciò che viene condiviso. Un kernel condiviso è spesso
molto difficile da concepire in primo luogo, e difficile da mantenere, perché è necessario avere una
comunicazione aperta tra i team e un accordo costante su ciò che costituisce il modello da
condividere. Tuttavia, è possibile avere successo se tutti i soggetti coinvolti sono impegnati
nell'idea che il kernel è meglio che andare Separato modi (vedere la sezione successiva).
Cliente-Fornitore
Un cliente-fornitore descrive una relazione tra due contesti delimitati e i rispettivi team, in cui il Fornitore è a
monte (l'U nel diagramma) e il Client è a valle (la D nel diagramma). Il Fornitore ha ondeggiato in
questa relazione perché deve fornire ciò di cui il Client ha bisogno. Spetta al Client pianificare con il
Fornitore per soddisfare le varie aspettative, ma alla fine il Fornitore determina cosa otterrà il Client
e quando. Si tratta di un rapporto molto tipico e pratico tra i team, anche all'interno della stessa
organizzazione, purché la cultura aziendale non permetta A Fornitore di essere completamente
autonomo e insensibile alle reali esigenze dei Clienti.

Conformista
Una relazione Conformista esiste quando ci sono team a monte e a valle, e il team a monte non ha
alcuna motivazione per supportare le esigenze specifiche del team a valle. Per vari motivi il team a
valle non può sostenere uno sforzo per tradurre il linguaggio onnipresente del modello a monte
per soddisfare le sue esigenze specifiche, in modo che il team si conforma al modello a monte così
com'è. Un team spesso diventerà un Conformista ad esempio, quando si integra con un modello molto
grande e complesso che è ben consolidato. Esempio: considera la necessità di conformarsi al
modello di Amazon.com quando integra come uno dei venditori affiliati di Amazon.
Strato di anticorruzione
Un livello anticorruzione è la relazione di mappatura del contesto più difensiva, in cui la squadra a valle crea un
livello di traduzione tra il suo linguaggio onnipresente (modello) e il linguaggio onnipresente
(modello) che è a monte di esso. Il livello isola il modello a valle dal modello a monte e converte tra i due.
Pertanto, questo è anche un approccio all'integrazione.
Quando possibile, è consigliabile provare a creare un livello Anticorruzione tra il modello a valle e un
modello di integrazione a monte, in modo da poter produrre concetti di modello sul lato
dell'integrazione che si adattano in modo specifico alle esigenze aziendali e che ti mantengono
completamente isolato da concetti stranieri. Eppure, proprio come l'assunzione di un traduttore
per agire tra due squadre che parlano lingue diverse, il costo potrebbe essere troppo alto in vari
modi per alcuni casi.

Aprire il servizio hostOpen Host Service

Un servizio Host aperto definisce un protocollo o un'interfaccia che consente l'accesso al contesto
delimitato come set di servizi. Il protocollo è "aperto" in modo che tutti coloro che hanno bisogno
di integrarsi con il contesto delimitato possono usarlo con relativa facilità. I servizi offerti dall'API
(Application Programming Interface) sono ben documentati e sono un piacere da usare. Anche se
si fosse Team 2 in questo diagramma e non si potrebbe prendere tempo per creare un livello
anticorruzione isolante per il lato dell'integrazione, sarebbe molto più tollerabile essere un
Conformista a questo modello di molti sistemi legacy che si possono incontrare. Si potrebbe dire
che la lingua del servizio Open Host è molto più facile da usare rispetto a quella di altri tipi di sistemi.
Lingua pubblicata
Un lingua pubblicata, illustrata nell'immagine in fondo alla pagina 57, è un linguaggio di scambio di
informazioni ben documentato che consente un semplice consumo e traduzione da parte di un numero qualsiasi
di contesti delimitati di utilizzo. I consumatori che leggono e scrivono possono tradurre da e nella
lingua condivisa con la certezza che le loro integrazioni siano corrette. Un linguaggio pubblicato di
questo tipo può essere definito con XML Schema, JSON Schema o un formato wire più ottimale, ad esempio
Protobuf o Avro. Spesso un servizio Host aperto serve e utilizza Un lingua pubblicata , che offre la migliore
esperienza di integrazione per terze parti. Questa combinazione rende le traduzioni tra due lingue
Ubiquitous molto convenienti.

Modi separati
Modi separati descrive una situazione in cui l'integrazione con uno o più contesti delimitati non
produrrà un payoff significativo attraverso il consumo di varie lingue Onnipresente. Forse la
funzionalità che cerchi non è completamente fornita da nessuna lingua ubiquitosa. In questo
caso produrre la propria soluzione specializzata nel contesto delimitato e dimenticare
l'integrazione per questo caso speciale.
Grande palla di fango
Hai già imparato molto su Grande palla di fango nei capitoli precedenti, ma rafforzerò i gravi
problemi che sperimenterai quando dovrai lavorare o integrarti con uno. Creare la propria
Grande Palla di Fango dovrebbe essere evitato come la peste.

Nel caso in cui questo non sia abbastanza avvertimento, ecco cosa succede nel tempo quando si
è responsabili della creazione di un Grande palla di fango: (1) Un numero crescente di aggregati
cross-contaminate a causa di connessioni e dipendenze ingiustificate. (2) Mantenere una parte del
Grande palla di Fango causa increspature sul modello, il che porta a problemi di "whack-a-mole". (3)
Solo la conoscenza tribale e l'eroismo, che parlano tutte le lingue contemporaneamente, salvano il
sistema dal collasso completo.
 Il problema è che ci sono già molte grandi sfere di fango là fuori nel vasto mondo dei sistemi software, e il
numero senza dubbio crescerà ogni mese. Anche se si è in grado di evitare la creazione di un Big Ball of Fango
utilizzando tecniche DDD, potrebbe essere ancora necessario integrare con uno o più. Se è necessario
integrare con uno o più, cercare di creare un livello di anticorruzione contro ogni sistema legacy un fine di
proteggere il proprio modello dal cruft che altrimenti inquinerebbe il modello con
l'incomprensibile pantano. Qualunque cosa tu faccia, non parlare quella lingua!

Fare buon uso della mappatura del contesto

Ci si potrebbe chiedere quale tipo specifico di interfaccia sarebbe fornito per consentire
l'integrazione con un determinato contesto delimitato. Dipende da ciò che fornisce il team
proprietario del contesto delimitato. Potrebbe essere RPC tramite SOAP, o interfacce RESTful con
le risorse, o potrebbe essere un
l'interfaccia di messaggistica utilizzando le code o Publish-Subscribe. Nelle situazioni meno
favorevoli si può essere costretti a utilizzare l'integrazione di database o file system, ma speriamo
che questo non accada. L'integrazione del database dovrebbe essere realmente evitata, e se si è
costretti a integrarsi in questo modo, si dovrebbe davvero essere sicuri di isolare il modello di
consumo per mezzo di un livello di anticorruzione.
Diamo un'occhiata a tre dei tipi di integrazione più affidabili. Passeremo dagli approcci di
integrazione meno robusti a quelli più robusti. In primo luogo esamineremo RPC, seguito da
RESTful HTTP, e poi la messaggistica.

RPC con SOAP

Le chiamate di procedura remota, o RPC, possono funzionare in diversi modi. Un modo comune
per utilizzare RPC è tramite il simple Object Access Protocol o SOAP. L'idea alla base di RPC con
SOAP è quella di rendere l'utilizzo di servizi da un altro sistema simile a una semplice procedura
locale o chiamata di metodo. Tuttavia, la richiesta SOAP deve viaggiare attraverso la rete,
raggiungere il sistema remoto, eseguire correttamente e restituire risultati sulla rete. Questo
comporta il potenziale per un errore di rete completo, o almeno una latenza che non è prevista
quando si implementa l'integrazione per la prima volta. Inoltre, RPC su SOAP implica anche un
accoppiamento forte tra un contesto delimitato del client e il contesto delimitato che fornisce il
servizio.
 Il problema principale con RPC, utilizzando SOAP o un altro approccio, è che può mancare di
robustezza. Se si verifica un problema con la rete o con il sistema che ospita l'API SOAP,
 apparentemente semplice chiamata di procedura avrà esito negativo del tutto, dando solo
risultati di errore. Non fatevi ingannare dall'apparente facilità d'uso.

Quando RPC funziona, e per lo più funziona, può essere un modo molto utile per l'integrazione.
Se è possibile influenzare la progettazione del servizio Contesto delimitato , sarebbe nel vostro
interesse se c'è un'API ben progettata che fornisce un servizio host aperto Con Un lingua pubblicata. In
entrambi i casi, il contesto delimitato del client può essere progettato con un livello anticorruzione per
isolare il modello da influenze esterne indesiderate.

RESTful HTTP
L'integrazione tramite RESTful HTTP concentra l'attenzione sulle risorse scambiate tra contesti
delimitati , nonché sulle quattro operazioni principali: POST, GET, PUT e DELETE. Molti
ricoprono che l'approccio REST all'integrazione funziona bene perché li aiuta a definire buone
API per l'elaborazione distribuita. E 'difficile discutere contro questa affermazione dato il
successo di Internet e Web.
 C'è un modo molto sicuro di pensare quando si utilizza RESTful HTTP. Non entrerò nei dettagli di
questo libro, ma si dovrebbe esaminare in esso prima di cercare di impiegare REST. Il libro REST in
Pratica [RiP] è un buon punto di partenza.
Un servizio con testo delimitato che offre un'interfaccia REST deve fornire un servizio host
aperto e una lingua pubblicata. Contesto delimitato Le risorse meritano di essere definite
come lingua pubblicata e combinate con gli URI REST costituiranno un servizio host aperto naturale.

RESTful HTTP tenderà a non riuscire per molti degli stessi motivi che viene RPC: errori di rete e
provider di servizi o latenza imprevista. Tuttavia, RESTful HTTP si basa sulla premessa di Internet e
chi può trovare un difetto con il track record del Web quando si tratta di affidabilità, scalabilità e
successo complessivo?

Un errore comune commesso quando si usa REST consiste nel progettare risorse che riflettono
direttamente le aggregazioni nel modello di dominio. Questa operazione forza ogni client in una relazione
Conformista in cui se il modello cambia forma anche le risorse. Quindi non vuoi farlo. Al contrario, le risorse
devono essere progettate in modo sintetico per seguire i casi d'uso guidati dal client. Per "sintetico"
intendo che al
 client le risorse fornite devono avere la forma e la composizione di ciò di cui hanno bisogno,
non ciò che il modello di dominio effettivo. Client the resources provided must have the shape
and composition of what they need, not what the actual domain model looks like. A volte il
modello sarà simile a quello di cui il cliente ha bisogno. Ma ciò di cui il cliente ha bisogno è ciò
che guida la progettazione delle risorse e non la composizione attuale del modello.

Messaggistica
Quando si usa la messaggistica asincrona per l'integrazione, molto può essere eseguito da un
client Delimitata Contesto sottoscrivendo gli eventi di dominio pubblicati dal proprio o un altro contesto
delimitato. L'utilizzo della messaggistica è una delle forme più solide di integrazione perché si
rimuove gran parte dell'accoppiamento temporale associato a forme di blocco come RPC e REST.
Dal momento che si prevede già la latenza dello scambio di messaggi, si tende a costruire sistemi
più robusti perché non ci si aspetta risultati immediati.

Invioo asincrono con RESTGoing asincrono con REST

È possibile eseguire la messaggistica asincrona utilizzando il polling basato su REST di un
set di risorse in crescita sequenziale. Utilizzando l'elaborazione in background, un client
esegue continuamente il polling per una risorsa del feed Atom del servizio che fornisce
un set sempre crescente di eventi di Dominio. Si tratta di un approccio sicuro per mantenere le
operazioni asincrone tra un servizio e i client, fornendo al contempo eventi aggiornati che
continuano a verificarsi nel servizio. Se il servizio non è più disponibile per qualche
motivo, i client tenteranno semplicemente a intervalli normali o torneranno indietro con
un nuovo tentativo, finché la risorsa del feed non sarà nuovamente disponibile.
Questo approccio viene descritto in dettaglio in Implementazione della progettazione
basata su dominio [IDDD]
 .

Evita i relitti dei treni di integrazione

 Quando un client Contesto delimitato (C1) si integra con un servizio Bounded Context (S1), C1
in genere non deve essere un sincrono, bloccando la richiesta a S1 come risultato diretto della gestione di una richiesta
effettuata. Vale a dire, mentre un altro client (C0) effettua una richiesta di blocco a
C1, non consentire a C1 di effettuare una richiesta di blocco a S1. In questo modo ha
un potenziale molto elevato per causare un naufragio ferroviario di integrazione tra
C0, C1 e S1. Questo può essere evitato utilizzando la messaggistica asincrona.

In genere un Aggregazione in un contesto delimitato pubblica un Evento di dominio , che potrebbe essere
utilizzato da un numero qualsiasi di parti interessate. Quando un sottoscrittore Contesto delimitato riceve
l'evento Dominio , verrà eseguita un'azione in base al tipo e al valore. In genere, verrà creata una nuova
aggregazione o un'aggregazione esistente nel contesto delimitato di utilizzo.

I conformisti dei consumer di eventi di dominio sono conformisti?

Ci si potrebbe chiedere come gli eventi di dominio possono essere utilizzati da un altro
contesto delimitato e non forzare l'utilizzo di contesto delimitato in una relazione
Conformista. Relazione. Come consigliato in Implementazione della progettazione basata il tuo
dominio [IDDD] e in particolare nel capitolo 13, "Integrazione di contesti delimitati", i
consumer non devono utilizzare i tipi di evento (ad esempio, classi) di un autore di
eventi. Piuttosto, dovrebbero dipendere solo dallo schema degli eventi, ovvero dalla
lingua pubblicata. Ciò significa in genere che se gli eventi vengono pubblicati come
JSON o forse come formato di oggetto più economico, il consumer deve utilizzare gli
eventi analizzandoli per ottenere gli attributi dei dati.
 Naturalmente, la presunzione presuppone che un Contesto delimitato contesto limitato di sottoscrizione
può sempre beneficiare di eventi non richiesti nella pubblicazione contesto delimitato. A volte,
tuttavia, un contesto delimitato Client dovrà inviare in modo proattivo un messaggio di comando ad un
contesto delimitato di servizio per forzare un'azione. In questi casi il contesto delimitato del client
continuerà a ricevere qualsiasi risultato come evento di dominio pubblicato.
 In tutti i casi di utilizzo della messaggistica per l'integrazione, la qualità della soluzione
complessiva dipenderà in larga misura dalla qualità del meccanismo di messaggistica scelto. Il
meccanismo di messaggistica dovrebbe supportare Consegna At-Least-Once [Reattivo] A garantire
che tutti i messaggi verranno ricevuti alla fine. Anche questo significa che la sottoscrizione
Contesto delimitato deve essere attuato come un Ricevitore idempotente [Reattivo] .

Recapito Al-Meno una volta [Reattivo] è un modello di messaggistica in cui il meccanismo di

messaggistica verrà periodicamente recapitato un determinato messaggio. Questa operazione verrà
eseguita in caso di perdita di messaggi, ricevitori a reazione lenta o inattivi e ricevitori che non
riescono a riconoscere la ricezione. A causa di questa progettazione del meccanismo di
messaggistica, è possibile che il messaggio venga recapitato più di una volta anche se il mittente
lo invia una sola volta. Ancora, che non deve essere un problema quando il ricevitore è progettato
per affrontare questo.

Ogni volta che un messaggio può essere recapitato più di una volta, il destinatario deve essere
progettato per gestire correttamente questa situazione. Ricevitore idempotente [Reattivo] descrive
come il destinatario di una richiesta esegue un'operazione in modo che produca lo stesso risultato
anche se viene eseguita più volte. Pertanto, se lo stesso messaggio viene ricevuto più volte, il
destinatario ne tratterà in modo sicuro. Ciò può significare che il ricevitore utilizza la deduplicazione e
ignora il messaggio ripetuto o riapplica in modo sicuro l'operazione con gli stessi risultati causati dal
recapito precedente.
A causa del fatto che i meccanismi di messaggistica introducono sempre comunicazioni
asincrone Richiesta-risposta [Reattivo], una certa quantità di latenza è comune e prevista. Le
richieste di servizio non devono (quasi) non bloccarsi fino a quando il servizio non viene
soddisfatto. Pertanto, progettare con la messaggistica in mente significa che si prevede sempre
per almeno una certa latenza, che renderà la soluzione complessiva molto più robusta fin
dall'inizio.
Esempio di mapping del contesto
Tornando a un esempio discusso nel Capitolo 2 ,"Progettazione strategica con contesti delimitati e
linguaggio onnipresente ", sorge una domanda sulla posizione del tipo di politica ufficiale. Tenere
presente che sono disponibili tre diversi tipi di criteri Pollici tre diversi contesti delimitati. Allora, dove
vive la "politica di registrazione" nell'impresa assicurativa? E 'possibile che appartiene alla divisione
di sottoscrizione dal momento che è dove ha origine. Ai fini di questo esempio, supponiamo che
appartenga alla divisione di sottoscrizione. In che modo gli altri contesti delimitati ne sono a
conoscenza?

Quando un componente di tipo Politica viene emesso nel contesto di sottoscrizione , è possibile
pubblicare un Evento di Dominio denominato PoliticaEdinata . Fornito tramite una sottoscrizione di
messaggistica, qualsiasi altro contesto delimitato può reagire a tale evento di Dominio , che potrebbe
includere la creazione di un componente Politica corrispondente nel contesto delimitato di sottoscrizione.
 Le PoliticaEdinata Evento di dominio conterrebbe l'identità del funzionario Politica . Qui è
PolicyId (criteri ID) . Tutti i componenti creati in un Contesto delimitato manterrebbe tale identità
per la riconducibilità al originario Contesto di sottoscrizione. In questo esempio l'identità viene
salvata come issuedPolicyId (idea di criterio) . Se c'è bisogno di più Politica dati rispetto al
PoliticaEdinata Dominio Evento fornito, la sottoscrizione Contesto delimitato può sempre
interrogare di nuovo il Contesto di sottoscrizione per ulteriori informazioni. Qui la sottoscrizione
Contesto delimitato utilizza il issuedPolicyId (idea di criterio) per eseguire una query sul Contesto
di sottoscrizione.

Arricchimento e trade-off di Query-Back

A volte c'è un vantaggio nell'arricchire gli eventi di dominio con dati sufficienti per
soddisfare le esigenze di tutti i consumer. A volte c'è un vantaggio per mantenere gli
eventi di Dominio sottile e consentire di eseguire query quando i consumer hanno
bisogno di più dati. La prima scelta, l'arricchimento, consente una maggiore
autonomia dei consumatori dipendenti. Se l'autonomia è il vostro requisito di guida,
considerare l'arricchimento.
D'altra parte, è difficile prevedere ogni pezzo di dati che tutti i consumatori
avranno mai bisogno in Eventi di dominio , e ci può essere troppo arricchimento se si
fornisce tutto. Ad esempio, potrebbe essere una scelta di sicurezza scadente per
arricchire notevolmente gli eventi di dominio. In questo caso, la progettazione di
eventi di dominio sottili e di un modello di query avanzato con sicurezza da cui i consumer
possono richiedere può essere la scelta desiderata.
A volte le circostanze richiederanno una combinazione equilibrata di entrambi gli
approcci.
 E come potrebbe la query sul Contesto di sottoscrizione Lavoro? Si potrebbe progettare un
RESTful Aprire il servizio hostOpen Host Service E Lingua pubblicata sul Contesto di
sottoscrizione. Un semplice HTTP GET con il issuedPolicyId (idea di criterio) recupererebbe il
IssuedPolicyData .

Probabilmente ti starai chiedendo i dettagli dei dati dell'evento di dominio rilasciato dalla
policy. Fornirò i dettagli di progettazione dell'evento di Dominio nel Capitolo 6 ,"Progettazione tattica con
eventi di dominio."
 Sei curioso di sapere cosa è successo all'esempio di contesto di gestione dei progetti Agile?
Allontanarsi da tale al dominio aziendale assicurativo ha permesso di esaminare DDD con più
esempi. Questo avrebbe dovuto aiutarti a capire ancora meglio il DDD. Non preoccuparti,
torneremo al contesto di gestione dei progetti Agile nel prossimo capitolo.

Riepilogo
In sintesi, hai imparato:
• Informazioni sui vari tipi di relazioni di Mappatura contesto, ad esempio Partenariato ,
Fornitore cliente e Livello Anticorruzione
• Come utilizzare l'integrazione di Mappatura del contesto con RPC, con RESTful HTTP e con la
messaggistica
• Come Eventi di dominio lavorare con la messaggistica
• Una base su cui è possibile creare l'esperienza di mappatura del contesto
Per una copertura approfondita delle mappe di contesto , vedere il capitolo 3
dell'implementazione di progettazione basata il tuo dominio [IDDD] .
Capitolo 5. Progettazione tattica con aggregati

Finora ho discusso la progettazione strategica con Contesti delimitati , Sottodomini e Mappe di

contesto. Qui vengono visualizzati due contesti delimitati, il dominio di base denominato Progetto Agile
Contesto di gestione e un sottodominio di supporto che fornisce strumenti di collaborazione tramite
l'integrazione di Contesto Mapping.

Ma per quanto riguarda i concetti che vivono all'interno di un contesto delimitato ? Ho

toccato questi, ma poi li coprirò in modo più dettagliato. Sono probabilmente le aggregazioni
nel modello.

Perché usato
Ognuno dei concetti cerchiati che si vede all'interno di questi due contesti delimitati è un
Aggregazione. L'unico concetto non cerchiato,Discussione, è modellato come un oggetto valore.
Anche così, ci concentriamo sugli aggregati in questo capitolo, e daremo uno sguardo più da vicino
a come modellare il Prodotto ,
BacklogItem , Rilascio e Sprint .

Che cos'è un'entità?

Un'entità modella una singola cosa. Ogni entità ha un'identità univoca in quanto è
possibile distinguerne l'individualità tra tutte le altre entità dello stesso tipo o di un tipo Entità
diverso. Molte volte, forse anche la maggior parte delle volte, un'entità sarà
modificabile, cioè il suo stato cambierà nel tempo. Tuttavia, un'entità non è
necessariamente modificabile e può essere immutabile. La cosa principale che separa
un'entità da altri strumenti di modellazione è la sua unicità, la sua individualità.
Vedere Implementazione della progettazione basata il tuo dominio [IDDD] per un
trattamento completo delle entità.

Che cos'è un Aggregazione ? Due sono rappresentati qui. Ogni Aggregazione è composta da una o
più entità , in cui un'entità viene denominata radice di , dove uno aggregazione. Le aggregazioni
possono anche avere oggetti valore composti su di essi. Come si nota qui, gli oggetti valore vengono
utilizzati all'interno di entrambe le aggregazioni .

Che cos'è un oggetto valore?

Un Oggetto Value o semplicemente un Valore , modella un insieme concettuale
immutabile. All'interno del modello il Valore è solo questo, un valore. A differenza di
un Entità , non ha un'identità univoca e l'equivalenza viene determinata confrontando
gli attributi incapsulati Valore digitare. Inoltre, un Oggetto Value non è una cosa, ma è
spesso usato per descrivere, quantificare o misurare un Entità.
Vedere Implementazione della progettazione basata il tuo dominio [IDDD] per una
copertura dettagliata degli oggetti valore.
 L'entità radice di ogni aggregazione possiede tutti gli altri elementi raggruppati al suo interno. Il nome
dell'entità radice è il nome concettuale dell'aggregazione. È necessario scegliere un nome che descriva
correttamente l'intero concettuale che i modelli di aggregazione.

Ogni aggregazione forma un limite di coerenza transazionale. Ciò significa che all'interno di un singolo
Aggregazione , tutte le parti composte devono essere coerenti, in base alle regole di business,
quando viene eseguito il commit della transazione di controllo nel database. Questo non significa necessariamente
che non si dovrebbe comporre altri elementi all'interno di un Aggregazione che non devono essere
coerenti dopo una transazione. Dopo tutto, un Aggregazione modella anche un insieme
concettuale. Ma si dovrebbe essere prima di tutto interessato con la coerenza transazionale. Il
limite esterno disegnato intorno al tipo di aggregazione 1 e al tipo di aggregazione 2 rappresenta una transazione
separata che avrà il controllo della persistenza atomica di ogni cluster di oggetti.

Significato più ampio della transazione

In una certa misura, l'uso delle transazioni nell'applicazione è un dettaglio di
implementazione. Ad esempio, un utilizzo tipico avrebbe un servizio dell'applicazione
[IDDD] che controlla la transazione di database atomica per conto del modello di
dominio. In un'architettura diversa, ad esempio il modello Attore [Reattivo] in cui viene
implementato ogni aggregazione
 come attore, le transazioni possono essere gestite utilizzando Approvvigionamento
eventi (vedere il capitolo successivo) con un database che non supporta le
transazioni atomiche. In entrambi i casi, ciò che intendo per "transazione" è come le
modifiche a un Aggregazione sono isolate e come le invarianti aziendali, le regole a cui il
software deve sempre aderire, sono garantiti per essere coerenti dopo ogni
operazione di business. Indipendentemente dal fatto che questo requisito sia
controllato da una transazione di database atomica o da altri mezzi, lo stato di
Aggregazione o la relativa rappresentazione tramite Approvvigionamento eventi ,
deve essere sempre sottoposto a transizione e manutenzione corretto.

I motivi per il limite transazionale sono motivati dall'azienda, perché è l'azienda che
determina quale deve essere uno stato valido del cluster in un determinato momento. In altre
parole, se il Aggregazione non è stata memorizzata in uno stato completo e valido, l'operazione
aziendale che è stata eseguita sarebbe considerato errato in base alle regole di business.

Per pensare a questo in un modo diverso, considera questo. Sebbene in questa posizione
siano rappresentate due aggregazioni, è necessario eseguire il commit solo di una delle due in una
singola transazione. Questa è una regola generale della progettazione di aggregazione: modificare ed
eseguire il commit di una sola istanza di Aggregazione Pollici una transazione. Ecco perché viene
visualizzata solo l'istanza di Tipo di aggregazione 1 all'interno di una transazione. Esamineremo presto le
altre regole del Design aggregato.
 Qualsiasi altro Aggregazione verrà modificato e sottoposto a commit in una transazione
separata. Ecco perché un Aggregazione è detto come un limite di coerenza transazionale. Quindi,
progetti le tue composizioni Aggregazione in modo da consentire la coerenza transazionale e il successo.
Come illustrato di seguito, un'istanza di Tipo aggregato 2 viene controllata in una transazione
separata dall'istanza di Tipo di aggregazione 1 .

Poiché le istanze di queste due aggregazioni sono progettate per essere modificate in
transazioni separate, come è possibile aggiornare l'istanza di Tipo di aggregazione 2 in base alle modifiche
apportate all'istanza di Tipo di aggregazione 1 , a cui il modello di dominio deve reagire? Questa è una buona
domanda; prenderemo in considerazione la risposta un po' più avanti in questo capitolo.
Il punto principale da ricordare da questa sezione è che le regole di business sono i driver per
determinare ciò che deve essere intero, completo e coerente alla fine di una singola transazione.

Aggregate Rules of Thumb

Consideriamo quindi le quattro regole di base della progettazione di aggregazione:Let's si considerino le
quattro regole di base Aggregazione Design:

1. Proteggere le invarianti aziendali all'interno dei limiti di aggregazione.

2. Progettare in piccolo Aggregati.
3. Fare riferimento ad altre aggregazioni solo in base all'identità.
4. Aggiornare altre aggregazioni utilizzando la coerenza finale.
Naturalmente, queste regole non sono necessariamente strettamente applicate da qualsiasi
"polizia DDD". Essi sono destinati come una guida solida in modo che, quando applicato con
attenzione, vi aiuterà a progettare aggregati che funzionano in modo efficace. In questo caso,
approfondiremo ciascuna di queste regole per vedere come dovrebbero essere applicate, ove
possibile.

Regola 1: Proteggere le invarianti aziendali all'interno di limiti aggregatiRule 1:

Protect Business Invariants inside Aggregate Boundaries
La Regola 1 significa che l'azienda dovrebbe determinare in ultima analisi Aggregazione
composizioni basate su ciò che deve essere coerente quando viene eseguito il commit di una
transazione. Nell'esempio a pagina 81 , Prodotto è progettato in modo tale che al termine di una
transazione tutti composti ProductBacklogItem istanze devono essere contabilizzati e coerenti con
il Prodotto Radice. Anche Sprint è progettato in modo tale che al termine di una transazione tutti
composti CommittedBacklogItem istanze devono essere contabilizzati e coerenti con il Sprint
Radice.
 La regola 1 diventa più chiara con un altro esempio. Ecco il BacklogItem Aggregazione. Esiste
una regola di business che indica: "Quando tutte le istanze di attività hanno oreRessiduo pari a
zero, lo stato BacklogItem deve essere impostato su FATTO." Pertanto, alla fine di una
transazione questa invariante aziendale molto specifica deve essere soddisfatta. L'azienda lo richiede.

Regola 2: Progettare aggregazioni di piccole dimensioni

Questa regola evidenzia che il footprint di memoria e l'ambito transazionale di ogni aggregazione
devono essere relativamente piccoli. Nel diagramma precedente l'aggregazione Aggregazione
rappresentata non è di dimensioni ridotte. In questo caso, Prodotto contiene letteralmente una raccolta
potenzialmente molto grande di BacklogItem istanze, una raccolta di grandi dimensioni di Rilascio
istanze e una raccolta di grandi dimensioni di Sprint istanze. Nel corso del tempo, queste raccolte
potrebbero diventare piuttosto grandi, con migliaia di istanze di BacklogItem e probabilmente centinaia
di istanze Rilascio e Sprint. Questo approccio progettuale è generalmente una scelta molto scarsa.
 Tuttavia, se si suddivide l'aggregazione di prodotti per formare quattro aggregazioni Separato si ottiene
questo: un piccolo Prodotto Aggregazione , un piccolo BacklogItem Aggregazione Un piccolo
Rilascio Aggregazione e un Piccolo Sprint Aggregazione. Questi caricare rapidamente, prendere
meno memoria, e sono più veloci per la raccolta di spazzatura. Forse la cosa più importante è che
queste aggregazioni avranno successo transazionale molto più frequentemente rispetto al
precedente aggregazione Prodotto di prodotti a grande grappolo.
Seguendo questa regola si aggiunge il vantaggio che ogni aggregazione sarà più facile da
utilizzare, perché ogni attività associata può essere gestita da un singolo sviluppatore. Ciò
significa anche che l'aggregazione Aggregazione sarà più facile da testare.
Un'altra cosa da tenere a mente quando si progetta Aggregati è il principio di responsabilità
singola (SRP). Se l'aggregazione Aggregazione sta tentando di eseguire troppe operazioni, non
segue SRP e questo probabilmente verrà detto nelle sue dimensioni. Chiedetevi, ad esempio, se il
vostro Prodotto è un'implementazione molto mirata di un prodotto Scrum, o se sta anche
cercando di essere altre cose. Qual è il motivo per modificare Prodotto : per renderlo un prodotto Scrum
migliore o per gestire elementi di backlog, rilasci e sprint? Si dovrebbe cambiare prodotto solo al fine di renderlo un
prodotto Scrum migliore.
Regola 3: Riferimento ad altre aggregazioni solo per identità
Ora che il prodotto di grandi dimensioni è stato suddiviso in quattro aggregazioni più piccole, in che modo ogni altro
deve fare riferimento agli altri dove necessario? Qui seguiamo la Regola 3, "Riferimento ad altre
aggregazioni solo per identità". In questo esempio si nota che BacklogItem , Rilascio e Sprint
fanno riferimento Un Prodotto tenendo premuto un Productid . Ciò consente di mantenere le aggregazioni
piccole e impedisce di raggiungere la modifica di più aggregazioni nella stessa transazione.
Ciò consente di mantenere la progettazione di aggregazione piccola ed efficiente, rendendo i requisiti di
memoria più bassi e il caricamento più rapido da un archivio di persistenza. Consente inoltre di
imporre alla regola di non modificare altre istanze di Aggregazione all'interno della stessa
transazione. Con solo le identità di altri aggregati , non esiste un modo semplice per ottenere un riferimento diretto
all'oggetto.
Un altro vantaggio dell'uso del riferimento solo per identità è che le aggregazioni possono essere
facilmente archiviate in qualsiasi tipo di meccanismo di persistenza, ad esempio database relazionale,
database di documenti, archivio chiave-valore e griglie/fabbriche di dati. Ciò significa che sono
disponibili opzioni per usare una tabella relazionale MySQL, un archivio basato su JSON, ad esempio
PostgreSQL o MongoDB, GemFire/Geode, Coherence e GigaSpaces.
Regola 4: Aggiornare altre aggregazioni utilizzando la coerenza finaleRule 4:
Update Other Aggregates Using Eventual Consistency
Chi uno BacklogItem si impegna a favore di un Sprint . Sia il BacklogItem E la Sprint deve reagire a
questo. È innanzitutto il BacklogItem che sa che è stato impegnato per un Sprint . Questo viene
gestito in una transazione, quando lo stato del BacklogItem viene modificato per contenere
SprintId (Id di stampa) della Sprint a cui è impegnata. Quindi, come possiamo garantire che il
Sprint è anche aggiornato con il IdBacklogItemId del nuovo impegno BacklogItem ?
 Come parte della transazione di BacklogItem Aggregazione pubblica un evento di Dominio denominato
BacklogItemCommitted . Le transazione BacklogItem viene completata e il relativo stato viene
mantenuto insieme all'evento di dominio Backlog-ItemCommitted. Quando Il BacklogItemCommitted
si fa strada a un sottoscrittore locale, viene avviata una transazione e lo stato dello Sprint viene
modificato per contenere il IdBacklogItemId dell'oggetto BacklogItem di cui è stato eseguito il
Commettere. Lo Sprint Contiene IdBacklogItemId all'interno di una nuova entità CommittedBacklogItem.
 Ricordiamo ora ciò che avete imparato nel Capitolo 4 ,"Progettazione strategica con
mappatura del contesto". Gli eventi di dominio vengono pubblicati da un'aggregazione e sottoscritti da un
contesto delimitato interessato. Il meccanismo di messaggistica fornisce gli eventi di Dominio Tutti parti
interessate tramite sottoscrizioni. Il contesto delimitato interessato può essere lo stesso da cui è stato pubblicato
l'evento Evento di dominio di dominio o potrebbe essere diversi contesti delimitati.

È solo che nel caso di BacklogItem Aggregazione e Sprint Aggregazione , il server di pubblicazione e il server
di sottoscrizione si trovano nello stesso contesto delimitato. Non è assolutamente necessario utilizzare un
prodotto middleware di messaggistica completo per questo caso, ma è facile farlo dal momento che
lo si utilizza già per
pubblicazione in altri contesti delimitati.

Se l'eventuale coerenza sembra spaventosa

Non c'è niente di incredibilmente difficile nell'usare la coerenza finale. Ancora, fino a
quando non è possibile acquisire una certa esperienza, si può essere preoccupati di
usarlo. In tal caso, è comunque necessario partizionare il modello in Aggregazioni in
base ai limiti delle transazioni definiti dall'azienda. Tuttavia, non vi è nulla che
impedisce di eseguire il commit delle modifiche a due o più aggregazioni in una singola transazione di database
atomico. È possibile scegliere di utilizzare questo approccio nei casi che si sa avrà
esito positivo, ma utilizzare la coerenza finale per tutti gli altri. Questo vi permetterà
di abituarsi alle tecniche senza prendere un passo iniziale troppo grande. È sufficiente
comprendere che questo non è il modo principale in cui le aggregazioni devono essere utilizzate
e di conseguenza potrebbero verificarsi errori transazionali.

Aggregazioni di modellazione
Ci sono alcuni hook che ti aspettano mentre lavori sul tuo modello di dominio, implementando le tue
aggregazioni. Un grande, brutto gancio è il modello di dominio anemico [IDDD] . Si tratta in cui si utilizza
un modello di dominio orientato agli oggetti e tutte le aggregazioni dispongono solo di funzioni di accesso pubbliche
(getter e setter) ma nessun comportamento aziendale reale. Questo tende ad accadere quando c'è
un focus tecnico piuttosto che commerciale durante la modellazione. La progettazione di un modello di
dominio anemico richiede di assumere tutto il sovraccarico di un modello di dominio senza rendersi
conto dei relativi vantaggi. Non prendere l'esca!
Prestare inoltre attenzione alla perdita di logica di business in Application Services sopra il
modello di dominio. Può accadere inosservato, proprio come l'anemia fisica. La delega della logica
di business dai servizi alle classi helper/utility non funzionerà bene. Le utility di servizio
presentano sempre una crisi di identità e non possono mai tenere le loro storie dritte. Inserire la
logica di business nel modello di dominio o subire bug sponsorizzati da un modello di dominio
anemico.
 E la programmazione funzionale?
Quando si utilizza la programmazione funzionale, le regole cambiano
considerevolmente. Mentre un modello di Dominio anemico è una cattiva idea quando si utilizza la
programmazione orientata agli oggetti, è in qualche modo la norma quando si applica la programmazione
funzionale. Questo perché la programmazione funzionale promuove la separazione
dei dati e del comportamento. I dati sono progettati come strutture di dati non
modificabili o tipi di record e il comportamento viene implementato come funzioni
pure che operano sui record non modificabili di tipi specifici. Anziché modificare i dati
che le funzioni ricevono come argomenti, le funzioni restituiscono nuovi valori. Questi
nuovi valori possono essere il nuovo stato di un'aggregazione o un evento di Dominio che
rappresenta una transizione in uno stato di aggregazione. stato.

Ho in gran parte affrontato l'approccio orientato agli oggetti in questo capitolo

perché è ancora il più utilizzato e ben compreso. Tuttavia, se si utilizza un linguaggio
funzionale e un approccio a DDD, tenere presente che alcune di queste linee guida
non sono applicabili o sono almeno soggette a regole di override.

Successivamente vi mostrerò alcuni dei componenti tecnici necessari per implementare un

progetto Aggregazione di base. Presumo che si sta utilizzando Scala, C , Java, o un altro linguaggio di
programmazione orientato agli oggetti. Gli esempi seguenti sono in C , ma sono molto comprensibili da
Scala, F , Java, Ruby, Python, e altri programmatori simili.

La prima cosa da fare è creare una classe per l'entità radice di aggregazione. Di seguito è riportata
una rappresentazione UML (Unified Modeling Language) dell'entità radice del prodotto. È inclusa
anche la Classe Prodotto in C, che estende una classe base denominata Entità . Questa classe di base
si occupa solo In Entity tipi a entità Standard di cose. Vedere Implementazione della progettazione
basata il tuo dominio [IDDD] per l'esaustivo
discussioni sulla progettazione e l'implementazione di Entità e Aggregazione.

Ogni entità radice di aggregazione deve avere un'identità univoca a livello globale. Un prodotto
nel contesto Agile Gestione dei progetti ha in realtà due forme di identità univoca a livello globale. Il Id
Tenant ambito l'entità radice all'interno di una determinata organizzazione del sottoscrittore. (Ogni
organizzazione che sottoscrive i servizi offerti è nota come tenant e pertanto ha un'identità
univoca per questo.) La seconda identità, anch'egli univoca a livello globale, è Productid . Questa
seconda identità distingue il prodotto da tutti gli altri all'interno dello stesso tenant. È incluso anche
il codice di C, che dichiara le due identità all'interno di Prodotto .
Utilizzo di oggetti valore
In questo caso, tenantId (tenantId) e Productid sono modellati come oggetti valore non modificabili.
Oggetti valore.

Successivamente si acquisiscono tutti gli attributi intrinseci o i campi necessari per trovare
l'aggregazione. Nel caso del Prodotto , ci sono sia Le descrizione che il nome . Gli utenti possono
cercare uno o entrambi questi per trovare ogni prodotto . Fornisco anche il codice di C , che
dichiara questi due attributi intrinseci.
 Naturalmente, è possibile aggiungere un comportamento semplice, ad esempio le funzioni di
accesso di lettura (getter) per gli attributi intrinseci. Questa operazione verrà probabilmente
eseguita utilizzando i getter di proprietà pubblica. Tuttavia, è possibile che non si desideri esporre
i setter come pubblici. Senza setter pubblici, come cambiano i valori di proprietà/attributo?
Quando si utilizza un approccio orientato agli oggetti (C , Scala e Java ), si modifica lo stato interno
utilizzando i metodi comportamentali. Se si usa un approccio funzionale (F , Scala e Clojure), le
funzioni restituiranno nuovi valori diversi dai valori passati come argomenti.

Dovresti essere in missione per combattere il modello di dominio anemico [IDDD] . Se si

espongono metodi setter pubblici, potrebbe portare rapidamente all'anemia, perché la logica
per l'impostazione dei valori su Prodotto verrebbe implementata all'esterno del modello. Pensaci
bene prima di farlo, e tieni a mente questo avvertimento.
 Infine, si aggiunge qualsiasi comportamento complesso. Qui abbiamo quattro nuovi metodi:
PlanBacklogItem() , PlannedProductBacklogItem() , ScheduleRelease() , e ScheduleSprint() . È
necessario aggiungere alla classe il codice di C' per ognuno di questi metodi.

Tenere presente che quando si usa DDD, è sempre possibile modellare un linguaggio
ubiquitous all'interno di un contesto delimitato. Pertanto, tutte le parti del Prodotto Aggregazione
sono modellate in base alla lingua ubiquitosa. sono modellati per il Non si compongono solo queste parti
composte. Tutto mostra armonia tra esperti di Dominio e sviluppatori del tuo team affiatato.

Scegli attentamente le tue astrazioni

Un modello software efficace si basa sempre su una serie di astrazioni che affrontano il modo di
fare dell'azienda. Esiste, tuttavia, la necessità di scegliere il livello appropriato di astrazione per
ogni concetto modellato.
Se segui la direzione del tuo linguaggio onnipresente , generalmente creerai le astrazioni
appropriate. È molto più facile modellare correttamente le astrazioni perché sono gli esperti di
Dominio che trasmettono almeno la genesi del linguaggio di modellazione. Ancora, a volte gli
sviluppatori di software che sono troppo zelanti per risolvere i problemi sbagliati cercheranno di
forzare in astrazioni che sono, beh, troppo astratto.
Ad esempio, nel Contesto di gestione dei progetti Agile abbiamo a che fare con Scrum. Ha senso
modellare Prodotto , BacklogItem , Rilascio E Sprint concetti di cui abbiamo discusso. Anche così,
cosa succederebbe se gli sviluppatori di software fossero meno preoccupati di modellare Lingua
onnipresente di Scrum, e più interessati a modellare una soluzione a tutti i Concetti di Scrum?
Se questo angolo sono perseguiti, gli sviluppatori sarebbe probabilmente venire con astrazioni
come ScrumElement (elementi di sistema) e ScrumElementContainer . Uno ScrumElement
(elementi di sistema) potrebbe soddisfare la necessità corrente di Prodotto e Elemento di backlog
e ScrumElementContainer potrebbe rappresentare i concetti ovviamente più espliciti di Rilascio e
Sprint . ScrumElement (elementi di sistema) avrebbe una proprietà Typename e verrebbe impostata
su "Prodotto" o il tuo "BacklogItem" nei casi appropriati. È possibile progettare lo stesso tipo di
proprietà Typename per ScrumElementContainer e consentire l'impostazione dei valori "Rilascio" Le
"Sprint".
Vedete i problemi con questo approccio? Ci sono più di alcuni, ma considerare quanto
segue:
• Il linguaggio del modello software non corrisponde al modello mentale degli esperti di
Dominio.
• Il livello di astrazione è troppo alto e si otterrà in guai profondi quando si inizia a modellare
i dettagli di ciascuno dei singoli tipi.
• Questo porterà alla creazione di casi speciali in ciascuna delle classi e probabilmente si
tradurrà in una gerarchia di classi complessa con approcci generali a problemi espliciti.
• Avrai molto più codice del necessario, perché stai cercando di risolvere un problema
irrisolvibile che non dovrebbe importa in primo luogo.
• Spesso il linguaggio delle astrazioni sbagliate troverà la sua strada anche
nell'interfaccia utente, che causerà confusione per gli utenti.
• Perderai molto tempo e denaro.
• Non sarai mai in grado di affrontare tutte le esigenze future in anticipo, il che
significa che se nuovi concetti Scrum verranno aggiunti in futuro, il tuo modello
esistente si rivelerà un fallimento nel prevedere tali esigenze.
Seguire un tale percorso può sembrare strano per alcuni, ma questo livello errato di astrazioni
viene spesso utilizzato in implementazioni tecnicamente ispirate.
Non farti prendere da questa trappola di implementazione seducente e altamente astratta.
Modella la lingua ubiquitosa in modo esplicito secondo il modello mentale degli esperti di dominio che
viene perfezionato dal tuo team. Modellando ciò di cui l'azienda ha bisogno oggi, risparmierai
una notevole quantità di tempo, budget, codice e imbarazzo. Ancora di più, si farà il business un
ottimo servizio modellando un contesto limitato accurato e utile che riflette un design Efficace.
Aggregazioni di ridimensionamento a destra
Ci si potrebbe chiedere come è possibile determinare i limiti di aggregazioni e impedire la
progettazione di cluster di grandi dimensioni, pur mantenendo i limiti di coerenza che
proteggeranno le vere invarianti aziendali. Qui ho fornito un approccio progettuale degno. Se
sono già state create aggregazioni di grandi cluster , è possibile utilizzare questo approccio per eseguire il refactoring in
più piccole, ma non si parte da tale prospettiva.
Prendere in considerazione questi passaggi di progettazione che consentono di raggiungere gli
obiettivi limite di coerenza:Consider these design steps that will help you reach consistency
boundary goals:
1.Concentrati innanzitutto sulla seconda regola della progettazione di Aggregate, "Progettare
Aggregati. " Iniziare creando ogni aggregazione con una sola entità , che fungerà da radice di
aggregazione. Non osare nemmeno posizionare due entità in un unico limite. Questa
opportunità arriverà abbastanza presto. Popolare ciascuna entità Entità Con i
campi/attributi/proprietà che si ritiene siano maggiormente associati alla singola entità
radice. Un suggerimento importante consiste nel definire ogni campo/attributo/proprietà
necessario per identificare e trovare l'aggregazione, Aggregazione nonché gli eventuali
campi/attributi/proprietà intrinseche aggiuntivi necessari per l'aggregazione Aggregazione
da costruire e lasciare in uno stato iniziale valido.
2.Ora concentrati sulla prima regola della progettazione di aggregazione, "Proteggi le invarianti
aziendali all'interno dei limiti aggregati". Il passaggio precedente è già stato affermato che almeno tutti i
campi/attributi intrinseci devono essere aggiornati quando l'aggregazionedi entità singola viene
mantenuta. Ma ora è necessario esaminare ciascuno dei vostri aggregati uno alla volta. In
questo modo per l'aggregazione Aggregazione A1, chiedere agli esperti di Dominio è qualsiasi altra
aggregazione definita deve essere aggiornata in relazione alle modifiche apportate all'aggregazione
Aggregazione A1. Creare un elenco di ognuna delle aggregazioni e delle relative regole di coerenza,
che indicheranno gli intervalli di tempo per tutti gli aggiornamenti basati sulla reazione. In altre
parole,"Aggrega a1" sarebbe l'intestazione di un elenco e altri tipi di aggregazione verrebbero
elencati in A1 se verranno aggiornati in reazione agli aggiornamenti A1.
3.Ora chiedi agli esperti di dominio quanto tempo può trascorrere fino a quando ciascuno degli
aggiornamenti basati sulla reazione può avvenire. Questo porterà a due tipi di specifiche: (a)
immediatamente, e (b) entro N secondi / minuti / ore / giorni. Un modo possibile per trovare la
soglia aziendale corretta è presentare un intervallo di tempo esagerato (ad esempio settimane
o mesi) che è ovviamente inaccettabile. Questo probabilmente farà sì che gli esperti aziendali
rispondano con un lasso di tempo accettabile.
4.Per ognuno degli intervalli di tempo immediati (3a), è consigliabile comporre queste due entità
all'interno dello stesso limite di aggregazione. Ciò significa, ad esempio, che aggregato A1 e
Aggregazione A2 saranno effettivamente composti in un nuovo aggregato A[1,2]. Ora le
 aggregazioni A1 (in modo inade e A2 come erano definite in precedenza non esisteranno più.
C'è solo l'aggregazione A[1,2].
5.Per ognuna delle aggregazioni che possono essere aggiornate dopo un determinato tempo
trascorso (3b), queste verranno aggiornate utilizzando la quarta regola di Progettazione
aggregata, "Aggiorna altre aggregazioni utilizzando la coerenza finale".
 In questa figura il nostro obiettivo è modellare l'aggregazione A1. Si noti dall'elenco A1 delle
regole di coerenza che A2 ha un intervallo di tempo immediato, mentre C14 ha un eventuale (30
secondi) intervallo di tempo. Di conseguenza, A1 e A2 sono modellati in un singolo aggregato
A[1,2]. Durante l'aggregazione di runtime A[1,2] pubblica un Evento di dominio che causa l'aggiornamento di
Aggregazione C14 alla fine.
Fai attenzione che l'azienda non insista sul fatto che ogni aggregato rientra nella specifica 3a
(coerenza immediata). Può essere una tendenza particolarmente forte quando molti nella
sessione di progettazione sono influenzati dalla progettazione del database e dalla modellazione
dei dati. Tali parti interessate avranno un punto di vista molto incentrato sulle transazioni.
Tuttavia, è molto improbabile che l'azienda abbia davvero bisogno di coerenza immediata in ogni
caso. Per modificare questa impostazione, è necessario dedicare del tempo a dimostrare come le
transazioni avranno esito negativo a causa di aggiornamenti simultanei da parte di più utenti in
diverse parti composte delle aggregazioni (ora) di grandi dimensioni. Inoltre, è possibile indicare
l'overhead di memoria che c'è con tali progettazioni di grandi cluster. Ovviamente questo tipo di
problemi sono ciò che stiamo cercando di evitare in primo luogo.
Questo esercizio indica che la coerenza finale è guidata dall'azienda, non tecnicamente
guidata. Naturalmente, è necessario trovare un modo per causare tecnicamente eventuali
aggiornamenti tra più aggregazioni , come illustrato nel capitolo precedente sul mappatura del
contesto. Anche così, è solo l'azienda che può determinare l'intervallo di tempo accettabile per
gli aggiornamenti che si verificano tra le varie entità. Alcuni sono immediati o transazionali, il che
significa che devono essere gestiti dalla stessa aggregazione. Alcuni sono eventuali, il che
significa che possono essere gestiti tramite eventi di dominio e messaggistica, ad esempio.
Considerare ciò che l'azienda avrebbe dovuto fare se gestisse le proprie operazioni solo tramite
sistemi cartacei può fornire alcune informazioni utili su come le varie operazioni basate su
dominio dovrebbero funzionare all'interno di un modello software delle operazioni aziendali.

Unità teabili
È inoltre consigliabile progettare aggregazioni in modo che siano un incapsulamento sonoro per
unit test. Le aggregazioni complesse sono difficili da testare. Seguire le linee guida di
progettazione precedenti consente di modellare aggregazioni teabili.
Gli unit test sono diversi dalla convalida delle specifiche aziendali (test di accettazione) come
descritto nel capitolo 2 , "Progettazione strategica con contesti delimitati e linguaggio onnipresente"
," e capitolo 7 , "Strumentidi accelerazione e gestione". Lo sviluppo degli unit test seguirà la
creazione di test di accettazione delle specifiche dello scenario. Ciò di cui ci occupiamo qui è testare
che l'aggregazione fa correttamente quello che dovrebbe fare. Si desidera eseguire il push di tutte
le operazioni per garantire Le correttezza, la qualità e la stabilità delle aggregazioni. È possibile utilizzare un
framework di unit test per
 questo, e c'è molta letteratura disponibile su come efficacemente unit test. Questi unit test
verranno associati direttamente al contesto delimitato e mantenuti con il relativo repository
del codice sorgente.

Riepilogo
In questo capitolo hai imparato:
• Che cos'è il modello Di aggregazione e perché è consigliabile usarlo
• L'importanza di progettare con un confine di coerenza in mente
• Informazioni sulle varie parti di un'aggregazione
• Le quattro regole empiriche della progettazione effettiva di Aggregazione
• Come è possibile modellare l'identità univoca di un'aggregazione
• L'importanza degli attributi di aggregazione e come impedire la creazione di un modello di dominio
anemico
• Come modellare il comportamento in un'eHow per modellare il comportamento in un'aggregazione
• Per aderire sempre alla lingua onnipresente all'interno di un contesto delimitato
• L'importanza di selezionare il giusto livello di astrazione per i vostri disegni
• Tecnica per ridimensionare correttamente le composizioni Aggregazione e come ciò
include la progettazione per la testabilità
Per un trattamento più approfondito di Entità , Oggetti valore e Aggregati , vedere i capitoli 5 , 6 e
10 di Implementazione Progettazione basata su dominio [IDDD] .
Capitolo 6. Progettazione tattica con eventi di dominio

Hai già visto un po 'nei capitoli precedenti su come vengono utilizzati gli eventi di Dominio. Un
evento di Dominio è un record di alcune occorrenze significative per l'azienda in un contesto limitato. Ormai sapete che
gli eventi di Dominio sono uno strumento molto importante per la progettazione strategica. Tuttavia, spesso durante
la progettazione tattica gli eventi di Dominio vengono concettualizzati e diventano parte del dominio
principale.
Per visualizzare tutta la potenza risultante dall'utilizzo di eventi di dominio , considerare il concetto
di coerenza causale. Un dominio aziendale fornisce coerenza causale se le operazioni correlate
alla causa, ovvero un'operazione causalmente, vengono visualizzate da ogni nodo dipendente di
un sistema distribuito nello stesso ordine [Causal] . Ciò significa che le operazioni correlate alla
causa deve essere eseguite in un ordine specifico e quindi una cosa non può accadere a meno che
non si verifichi un'altra cosa prima di essa. Forse ciò significa che un Aggregazione non può essere creato
o modificato fino a quando non viene chiaro che si è verificata un'operazione specifica a un'altra aggregazione: :

1. Sue pubblica un messaggio che dice: "Ho perso il portafoglio!"

2. Gary dice in risposta: "È terribile!"
3. Sue pubblica un messaggio che dice: "Non ti preoccupare, ho trovato il mio portafoglio!"
4. Gary risponde: "È fantastico!"
 Se questi messaggi sono stati replicati su nodi distribuiti, ma non in ordine causale, potrebbe
sembrare che Gary abbia detto, "Fantastico!" al messaggio "Ho perso il portafoglio!" Il messaggio
"That's great!" non è direttamente o causalmente correlato a "Ho perso il mio portafoglio!" e
questo non è sicuramente ciò che Gary vuole Sue o
chiunque altro da leggere. Pertanto, se la causalità non viene raggiunta nel modo corretto, il
dominio complessivo sarebbe sbagliato o almeno fuorviante. Questo tipo di architettura di
sistema causale e linearizzata può essere facilmente raggiunto attraverso la creazione e la
pubblicazione di eventi di dominio ordinati correttamente.
Da sforzi di progettazione tattica gli eventi di dominio diventano una realtà nel tuo modello di dominio e possono
di conseguenza essere pubblicati e utilizzati nel tuo contesto delimitato e da altri. È un modo
molto potente per informare gli ascoltatori interessati di eventi importanti che hanno avuto
luogo. Ora imparerai a modellare gli eventi di dominio e a usarli nei contesti delimitati.

Progettazione, implementazione e utilizzo di eventi di dominio

Di seguito vengono illustrati i passaggi necessari per progettare e implementare in modo efficace gli eventi di
dominio nel contesto delimitato. In seguito, verranno visualizzati anche esempi di utilizzo degli eventi di
Dominio. vengono utilizzati.

Questo codice di C 'net potrebbe essere considerato l'interfaccia minima che ogni evento di
Dominio deve supportare. In genere si desidera comunicare la data e l'ora in cui si è verificato
l'evento di dominio, in modo che venga fornito dalla proprietà Evento di dominio OccurredOn. Questo dettaglio non
è una necessità assoluta, ma è spesso utile. Pertanto, i tipi di evento di Dominio potrebbero
probabilmente implementare questa interfaccia.
Devi prestare attenzione a come denominare i tipi di Evento di dominio. Le parole che usi
dovrebbero riflettere il linguaggio onnipresente del tuo modello. Queste parole formeranno un ponte tra
gli avvenimenti nel vostro modello e nel mondo esterno. È fondamentale che comunichiate bene i
vostri avvenimenti.
 I nomi dei tipi di Evento di dominio devono essere un'istruzione di un'occorrenza passata, ovvero
un verbo nel tempo passato. Di seguito sono riportati alcuni esempi di Contesto di gestione dei
progetti Agile : ProdottoCreato , ad esempio, indica che un prodotto Scrum è stato creato in un
momento passato. Gli altri eventi di Dominio sono ReleaseScheduled , SprintProgrammato ,
BacklogItemPlanned e BacklogItemCommitted . Ognuno dei nomi indica in modo chiaro e
conciso ciò che è successo nel dominio principale.

Si tratta di una combinazione del nome dell'evento di dominio e delle relative proprietà che
trasmette completamente il record di ciò che è accaduto nel modello di dominio. Ma quali
proprietà deve contenere un Evento di Dominio?

Chiedetevi: "Qual è lo stimolo dell'applicazione che causa la pubblicazione dell'evento di

dominio?" Nel caso di ProdottoCreato è presente un comando che lo causa (un comando è solo
la forma oggetto di un metodo/richiesta di azione). Il comando è denominato Creaprodotto .
Quindi si può dire che ProdottoCreato è il risultato di un Creaprodotto comando.
 Il comando Creaprodotto dispone di diverse proprietà: (1) tenantId (tenantId) che identificarlo di
sottoscrizione, (2) Productid che identifica il prodotto univoco creato, il (3) Nome prodotto e (4) il
descrizione del prodotto . Ognuna di queste proprietà è
essenziale per la creazione di un Prodotto .

Pertanto, l'evento di dominio ProdottoCreato deve contenere tutte le proprietà fornite con il
comando che ne ha causato la creazione: (1) tenantId (tenantId) , (2) Productid , (3) Nome e
(4) Descrizione . Questo informerà completamente e con precisione tutti i sottoscrittori di ciò
che è accaduto nel modello, vale a dire, è stato creato un Prodotto, è stato per il tenant identificato con
il tenantId (tenantId) , il prodotto è stato identificato in modo univoco con Productid e il Prodotto aveva
il nome e la descrizione assegnati.

Questi cinque esempi forniscono una buona idea delle proprietà che devono essere incluse nei
vari eventi di dominio pubblicati dal contesto di gestione dei progetti Agile. Ad esempio, quando viene
eseguito il commit di un BacklogItem in uno Sprint , viene creata un'istanza e pubblicata l'evento di Dominio
BacklogItemCommitted . Questo evento di dominio Contiene tenantId (tenantId) ,
idbacklogItemId dell'oggetto BacklogItem di cui è stato eseguito il commit e che cosa sprintId (idprint) dello
Sprint a cui è stato eseguito il Commettere.
Come descritto nel Capitolo 4 ,"Progettazione strategica con mappatura del contesto ", ci sono
momenti in cui un Evento di dominio può essere arricchito con dati aggiuntivi. Ciò può essere particolarmente
utile per gli utenti che non desiderano eseguire query sul contesto delimitato per ottenere dati aggiuntivi di
cui hanno bisogno. Anche così, è necessario fare attenzione a non riempire un Evento di dominio con così
tanti dati che perde il suo significato. Si consideri, ad esempio, il problema con BacklogItemCommitted che contiene
l'intero stato di BacklogItem . Secondo questo Evento di dominio , che cosa è realmente accaduto? Tutti i
dati aggiuntivi possono rendere poco chiaro, a meno che non si richieda al consumatore di avere una
profonda comprensione
 Elemento BacklogItem. Considerare inoltre l'utilizzo di BacklogItemUpdated con lo stato completo di
BacklogItem , anziché fornire BacklogItemCommitted . Cosa è successo a BacklogItem è molto
poco chiaro, perché il consumer dovrebbe confrontare l'ultimo BacklogItemUpdated al
precedente BacklogItemUpdated per capire cosa si è effettivamente verificato per il
BacklogItem .

Per rendere più chiaro l'uso corretto degli eventi di dominio, esaminiamo uno scenario. Il
proprietario del prodotto esegue il commit di un BacklogItem in uno Sprint . Il comando stesso fa sì
che BacklogItem e Sprint da caricare. Il comando viene quindi eseguito in BacklogItem
Aggregazione.
In questo modo lo stato di BacklogItem da modificare e quindi l'evento di
Dominio BacklogItemCommitted viene pubblicato come risultato.

È importante che l'oggetto Aggregate modificato e l'evento di Dominio vengano salvati insieme nella
stessa transazione. Se si utilizza uno strumento di mapping relazionale a oggetti, è necessario salvare
l'aggregazione Aggregazione in una tabella e l'evento Evento di dominio di dominio in una tabella dell'archivio
eventi e quindi eseguire il commit della transazione. Se si utilizza Approvvigionamento eventi , lo
stato dell'aggregazione è completamente rappresentato dagli eventi di Dominio stessi. Discuto Evento
Sourcing nella sezione successiva di questo capitolo. In entrambi i casi, la persistenza dell'evento
Evento di dominio di dominio nell'archivio eventi mantiene l'ordine causale rispetto a quanto è accaduto
nel modello di dominio.
 Un Evento di dominio volta salvato nell'archivio eventi, l'evento di dominio può essere pubblicato
per tutte le parti interessate. Questo potrebbe essere all'interno del proprio contesto delimitato E
la contesti delimitati esterni. Questo è il tuo modo di dire al mondo che qualcosa di degno di nota si è
verificato nel tuo dominio principale.
Si noti che il semplice salvataggio dell'evento di dominio nell'ordine causale non garantisce che
arrivi ad altri nodi distribuiti nello stesso ordine. Così, è anche responsabilità del contesto
Contingente che consuma riconoscere la corretta causalità. Potrebbe trattarsi del tipo di Evento di dominio stesso che
può indicare Le causalità o di metadati associati all'evento Evento di dominio di dominio , ad esempio una
sequenza o un identificatore causale. La sequenza o l'identificatore causale indicherebbe la causa che ha
causato questo Evento di dominio e se la causa non è stata ancora vista, il consumer deve attendere di applicare
l'evento appena arrivato fino all'arrivo della causa. In alcuni casi è possibile ignorare gli eventi di
Dominio latenti che sono già stati sostituiti dalle azioni associate a uno successivo; in questo caso la
causalità ha un impatto sprezzante.

Un altro punto su ciò che può causare un evento di Dominio è degno di nota. Anche se spesso è
un comando basato sull'utente generato dall'interfaccia utente che causa il verificarsi di un evento, a
volte gli eventi di dominio possono essere causati da un'origine diversa. Ciò potrebbe provenire da un timer che
scade, ad esempio alla fine del giorno lavorativo o alla fine di una settimana, un mese o un anno.
In casi come questo non sarà un comando che causa l'evento, perché la fine di un certo periodo di
tempo è un dato di fatto. Non è possibile rifiutare il fatto che un certo intervallo di tempo è
scaduto e, se l'azienda si preoccupa di questo fatto, la scadenza dell'ora è modellata come un
Evento di dominio e non come un comando.
 Inoltre, un periodo di tempo così in scadenza avrà generalmente un nome descrittivo che
diventerà parte del linguaggio onnipresente. Ad esempio, "Anno fiscale terminato" può essere un
evento importante a cui l'azienda deve reagire. Inoltre, le 16:00 (16:00) a Wall Street sono note
come "Mercati chiusi" e non solo come 16:00. Pertanto, si dispone di un nome per quel particolare evento di
Dominio basato sul tempo.
 Un comando è diverso da un Evento di dominio in quanto un comando può essere rifiutato come
inappropriato in alcuni casi, ad esempio a causa della fornitura e della disponibilità di alcune
risorse (prodotto, fondi e così via) o di un altro tipo di convalida a livello aziendale. Pertanto, un
comando può essere rifiutato, ma un Evento di dominio è una questione di storia e non può essere logicamente
negato. Anche così, in risposta a un evento di Dominio basato sul tempo potrebbe essere che l'applicazione
dovrà generare uno o più comandi per chiedere all'applicazione di eseguire alcuni set di azioni.

Approvvigionamento eventi
Approvvigionamento eventi può essere descritto come persistente di tutti gli eventi di Dominio che si
sono verificati per un'istanza di che si sono verificati per un Aggregazione come record delle modifiche rispetto a tale
istanza di Aggregate. Anziché rendere persistente che cosa stato di aggregazione nel suo complesso,
vengono archiviati tutti i singoli eventi di Dominio che si sono verificati. Esaminiamo il modo in cui questo è
supportato.
Tutti gli eventi di dominio che si sono verificati per un'istanza di Aggregazione ordinati come si sono verificati in
origine, costituiscono il relativo flusso di eventi. Il flusso di eventi inizia con il primo evento di Dominio che
si è mai verificato per l'istanza di Aggregate e continua fino all'ultimo evento di Dominio che si è verificato. Quando si
verificano nuovi eventi di dominio per una determinata istanza di Aggregazione questi vengono aggiunti alla fine del relativo
flusso di eventi. La riapplicazione del flusso di eventi ad Aggregazione consente di ricostituire il relativo
stato dalla persistenza in memoria. In altre parole, quando si utilizza Evento Sourcing Un Aggregazione
aggregate che è stato rimosso dalla memoria per qualsiasi motivo viene ricostituito interamente dal relativo flusso di
eventi.
Nel diagramma precedente, il primo evento di Dominio che si è verificato è stato
BacklogItemPlanned ;
 successivo è stato BacklogItemStoryDefined ; e l'evento che si è appena verificato è
BacklogItemCommitted . Il flusso di eventi completo è attualmente composto da questi tre
eventi e seguono l'ordine descritto e visualizzato nel diagramma.
Ognuno degli eventi di dominio che si verifica per una determinata istanza di Aggregazione è causato da un
comando, come descritto in precedenza. Nel diagramma precedente, è il comando
CommitBacklogItemToSprint che è stato appena gestito e ciò ha causato l'evento di Dominio
BacklogItemCommitted. che si verifichi.

L'archivio eventi è solo una raccolta o una tabella di archiviazione sequenziale in cui vengono
aggiunti tutti gli eventi di dominio. Poiché l'archivio eventi è di sola aggiunta, rende il
meccanismo di archiviazione estremamente veloce, pertanto è possibile pianificare un Dominio di
base che utilizza Evento Sourcing per avere una velocità effettiva molto elevata, bassa latenza ed
essere in grado di scalabilità elevata.

Consapevole delle prestazioni

Se uno dei problemi principali è il rendimento, si apprezzerà conoscere la
memorizzazione nella cache e le istantanee. Prima di tutto, le aggregazioni con prestazioni
più elevate saranno quelle memorizzate nella cache, in cui non è necessario ricostituirle
dall'archiviazione ogni volta che vengono utilizzate. L'utilizzo del modello Attore con
attori come aggregazioni [Reattivo] è uno dei modi più semplici per mantenere lo stato
delle aggregazioni nella cache.
Un altro strumento a cui si è a disposizione sono gli snapshot, in cui il tempo di
caricamento delle aggregazioni che sono state rimosse dalla memoria può essere
ricostituito in modo ottimale senza ricaricare ogni Evento di dominio da un flusso di eventi.
Ciò si traduce nel mantenimento di uno snapshot di uno stato incrementale
dell'oggetto ,oggetto o record nel database. Gli snapshot sono descritti in modo più
dettagliato in Implementazione della progettazione basata su Dominio [IDDD] e modelli di
messaggistica reattiva con il modello attore [Reattivo] .

Uno dei maggiori vantaggi dell'utilizzo di Approvvigionamento eventi è che salva un record di tutto
ciò che è mai accaduto nel Dominio principale, a livello di occorrenza individuale. Questo può essere molto
utile per la tua azienda per molte ragioni, quelle che puoi immaginare oggi, come conformità e analisi
e quelle che non realizzerai fino a tardi. Ci sono anche vantaggi tecnici. Ad esempio, gli sviluppatori di
software possono utilizzare i flussi di eventi per esaminare le tendenze di utilizzo ed eseguire il debug del codice
sorgente.
 È possibile trovare la copertura delle tecniche di Approvvigionamento eventi Pollici
Implementazione Progettazione basata su dominio [IDDD] . Inoltre, quando si utilizza
Approvvigionamento eventi si è quasi certamente obbligati a utilizzare CQRS. È inoltre possibile
trovare discussioni su questo argomento in Implementazione della progettazione basata il tuo dominio [IDDD] .

Riepilogo
In questo capitolo hai imparato:
• Come creare e assegnare un nome ai tuoi eventi di dominio
• L'importanza di definire e implementare un'interfaccia standard per gli eventi di dominio
• Che il nome del vostro Eventi di dominio bene è particolarmente importante
• Come definire le proprietà degli eventi di Dominio
• Che alcuni eventi di dominio possono essere causati da comandi, mentre altri possono
verificarsi a causa del rilevamento di un altro stato che cambia, ad esempio una data o
un'ora
• Come salvare gli eventi di Dominio Pollici un archivio eventi
• Come pubblicare gli eventi di Dominio dopo che sono stati salvati
• Informazioni sull'origine eventi e su come gli eventi di Dominio possono essere archiviati e
utilizzati per rappresentare lo stato delle aggregazioni
Per un trattamento approfondito degli eventi di dominio e dell'integrazione, vedere i capitoli 8 e 13
di Implementazione Progettazione basata su dominio [IDDD] .
Capitolo 7. Strumenti di accelerazione e gestione

Quando usiamo DDD, siamo alla ricerca di apprendimento profondo su come funziona l'azienda e
quindi di modellare il software in base alla portata del nostro apprendimento. È davvero un processo
di apprendimento, sperimentazione, sfida, apprendimento e modellazione di nuovo. Dobbiamo
scricchiolare e distillare le conoscenze in grandi quantità e produrre un design efficace per soddisfare
le esigenze strategiche di un'organizzazione. La sfida è che dobbiamo imparare in fretta. In un settore
frenetico di solito lavoriamo contro il tempo, perché il tempo conta, e il tempo generalmente guida
molte delle nostre decisioni, forse anche più di quanto dovrebbe. Se non consegniamo in tempo e nel
budget, non importa quello che abbiamo raggiunto con il software, sembra che abbiamo fallito. E
tutti contano su di noi per avere successo in ogni modo.
Alcuni hanno fatto sforzi per convincere la direzione che la maggior parte delle stime del tempo
di progetto sono prive di valore e che non possono essere utilizzate con successo. Non sono sicuro
di come questi sforzi stanno funzionando nel grande, ma ogni cliente con cui lavoro è ancora sotto
pressione per consegnare entro tempi molto specifici, che costringe timeboxing nel processo di
progettazione / implementazione. Nella migliore delle casi è una lotta costante tra lo sviluppo e la
gestione del software.
Sfortunatamente, una risposta comune a questa pressione negativa è cercare di economizzare
e accorciare le tempistiche eliminando il design. Ricordiamo dal primo capitolo che il design è
inevitabile, e che o si farà male a causa di un cattivo design, o si avrà successo con un design
efficace, e possibilmente anche con un buon design. Quindi, quello che dovresti tentare di fare è
soddisfare le esigenze del tempo e progettare in modo accelerato, utilizzando approcci che ti
aiuteranno a fornire il miglior design possibile entro i limiti di tempo che affronti.
A tal fine fornisco alcuni strumenti molto utili per l'accelerazione progettuale e la gestione
dei progetti in questo capitolo. Prima di tutto discuto di Storming di eventi e poi concludo con
un modo per sfruttare gli artefatti prodotti da quel processo di collaborazione per creare stime
significative e, soprattutto, raggiungibili.
Storming di eventi
Event Storming è una tecnica di progettazione rapida che ha lo scopo di coinvolgere sia gli esperti di
Dominio E che gli sviluppatori in un processo di apprendimento frenetico. È focalizzata sul processo aziendale
e aziendale piuttosto che su sostantivi e dati.
Prima di imparare Storming di eventi Ho usato una tecnica che ho chiamato modellazione
basata su eventi. Di solito comportavano conversazioni, scenari concreti e modellazione
incentrata sugli eventi utilizzando UML molto leggero. I passaggi specifici dell'UML potrebbero
essere eseguiti solo su una lavagna e potrebbero anche essere acquisiti in uno strumento.
Tuttavia, come probabilmente saprete, pochi uomini d'affari sono informati e competenti anche
in un uso minimalista di UML. Così, questo ha lasciato la maggior parte della parte di
modellazione dell'esercizio a me o un altro sviluppatore che ha capito le basi di UML. Era un
approccio molto utile, ma doveva esserci un modo per coinvolgere più direttamente gli esperti
aziendali nel processo. Questo probabilmente significava lasciare fuori UML a favore di uno
strumento più coinvolgente.
Ho appreso per la prima volta di Storming di eventi anni fa da Alberto Brandolini, [ziobrando]
che aveva anche sperimentato un'altra forma di modellazione basata sugli eventi. In un'occasione,
essendo a corto di tempo, Alberto decise che avrebbe dovuto abbandonare l'UML e usare invece
le note adesive. Questa è stata la nascita di un approccio all'apprendimento rapido e alla
progettazione del software che ha portato tutti nella stanza molto direttamente coinvolti nel
processo. Ecco alcuni dei suoi vantaggi:
• Si tratta di un approccio molto tattile. Ognuno riceve un pad di note adesive e una penna ed è
responsabile di contribuire alle sessioni di apprendimento e design. Sia gli uomini d'affari che
gli sviluppatori stanno sullo stesso piano man mano che imparano insieme. Ognuno fornisce
input alla lingua onnipresente.
• Si concentra tutti sugli eventi e il processo di business, piuttosto che sulle classi e il database.
• Si tratta di un approccio molto visivo, che respinge il codice dalla sperimentazione e mette
tutti su un piano di parità con il processo di progettazione.
• È molto veloce e molto economico da eseguire. Si può letteralmente storm out un nuovo
dominio di base in formato approssimativo in poche ore, piuttosto che settimane. Se si scrive
 qualcosa su una nota adesiva che poi si decide non funziona, si guadare la nota adesiva e
gettarlo via. Ti costa solo un centesimo o due per quell'errore, e nessuno resisterà
all'opportunità di affinare a causa dello sforzo già investito.
• Il tuo team avrà dei progressi nella comprensione. Periodo. Succede ogni volta. Alcuni
verranno alla sessione pensando che hanno una buona comprensione del nucleo specifico
 modello di business, ma non importa, partono sempre con una maggiore comprensione
e anche nuove intuizioni sul processo di business.
• Tutti imparano qualcosa. Che tu sia un esperto di dominio o uno sviluppatore di software, ti allontanerai
dalle sessioni con una comprensione nitida e chiara del modello a portata di mano. Questo è
diverso dal raggiungimento di scoperte ed è importante di per sé. In molti progetti, almeno
alcuni membri del progetto, e possibilmente molti, non capiscono su cosa stanno lavorando
fino a quando non è troppo tardi e il danno è già nel codice. L'estrazione di un modello aiuta
tutti a chiarire le incomprensioni e ad andare avanti con una direzione e uno scopo unificati.
• Ciò implica che si identificano anche i problemi sia nel modello che nella comprensione il
più presto e rapidamente possibile. Risolvere le incomprensioni e sfruttare il risultato
come nuove intuizioni. Tutti nella stanza ne traggono beneficio.
• È possibile utilizzare Storming di eventi sia per la modellazione a immagine generale che per la modellazione
a livello di progetto. Fare big-picture storming sarà meno preciso, mentre l'assalto a livello di
progettazione vi condurrà verso determinati artefatti software.
• Non è necessario limitare le sessioni di tempesta a uno. Puoi iniziare con una sessione di
tempesta di due ore, quindi fare una pausa. Dormi sui tuoi conseguimenti e torna il giorno
successivo per trascorrere un'altra ora o due per espanderti e perfezionare. Se lo fai per
due ore al giorno per tre o quattro giorni, otterrai una profonda comprensione del tuo
Dominio principale e le integrazioni con l'ambiente circostante Sottodomini.
Ecco un elenco delle persone, mentalità, e forniture è necessario tempestare un modello:
• Avere le persone giuste è essenziale, il che significa che gli esperti di Dominio e gli
sviluppatori che devono lavorare sul modello. Tutti avranno alcune delle domande e
alcune delle risposte. Per supportarsi a vicenda, tutti devono essere nella stessa stanza
durante le sessioni di modellazione.
• Tutti dovrebbero venire con una mente aperta che sia libera da un giudizio rigoroso.
L'errore più grande che vedo durante le sessioni di Evento Storming è che le persone
cercano di essere troppo corrette troppo presto. Si dovrebbe piuttosto essere
completamente determinato a creare troppi eventi. Più eventi è meglio di un numero
inferiore di eventi, perché questo è ciò che ti farà imparare di più. C'è tempo per affinare
più tardi, e raffinatezza è veloce ed economico.
• Avere a portata di mano un assortimento di colori di note adesive, e un sacco di loro. Come
minimo hai bisogno di questi colori: arancione, viola / rosso, azzurro, giallo pallido, lilla e rosa.
Potresti scoprire che altri colori (come il verde; vedi esempi successivi) sono utili. Le dimensioni
della nota adesiva possono essere quadrate (3 pollici per 3 pollici, o 7,62 cm per 7,62 cm)
piuttosto che la più ampia varietà che sono rettangolari. Non c'è bisogno di scrivere molto sulla
nota adesiva; di solito bastano poche parole. Prendi in considerazione l'idea di ottenere la
varietà extra-sticky. Non vuoi che le tue note appiccicose cadano sul pavimento.
• Fornire una penna pennarello nero per ogni persona, che consentirà la scrittura a mano per
mostrare grassetto e chiaro. I pennarelli a punta fine sono i migliori.
• Trovare un ampio muro in cui è possibile modellare. La larghezza è più importante
dell'altezza, ma la superficie di modellazione deve essere alta circa un metro/metro. La
larghezza dovrebbe essere praticamente illimitata, ma qualcosa nell'intervallo di 10 metri /
iarde dovrebbe essere considerato un minimo. Al posto di un tale muro essere disponibile, è
sempre possibile utilizzare un lungo tavolo per conferenze o il pavimento. Il problema con
una tabella è che alla fine limiterà lo spazio di modellazione. Il problema con il pavimento è
che potrebbe non essere accessibile a tutti i membri del team. Un muro è meglio.
 • Ottenere un lungo rotolo di carta, come spesso si può trovare nei negozi d'arte,
l'insegnamento negozi di forniture, e anche nei negozi Ikea. La carta deve essere alle
dimensioni descritte in precedenza, con almeno 10 metri / iarde in larghezza e 1 metro /
metro in altezza. Appendere la carta sulla parete con del nastro adesivo. Alcuni possono
decidere di rinunciare alla carta e lavorare solo su lavagne. Questo può funzionare per un po
', ma le note adesive tendono a perdere l'adesione nel tempo sulle lavagne, soprattutto se
vengono tirate su e rebloccate in luoghi diversi. Gli adesivi aderiscono più a lungo quando
vengono applicati alla carta. Se avete intenzione di modellare per brevi periodi di tempo per
tre o quattro giorni, piuttosto che in una lunga sessione, la longevità di appiccicosità è
importante.
Date le forniture di base e avere le persone giuste che partecipano alla sessione, sei pronto
per iniziare. Considera ciascuno dei passaggi, uno per uno.

1.Fai uscire il processo di business creando una serie di eventi di dominio su note adesive. Il
colore più popolare da usare per gli eventi di dominio è l'arancione. L'utilizzo
dell'arancione fa risaltare maggiormente gli eventi di dominio sulla superficie di modellazione.
Di seguito sono riportate alcune linee guida di base da utilizzare durante la creazione degli
eventi di Dominio:
• La creazione di eventi di dominio prima dovrebbe sottolineare che abbiamo il nostro
primo e principale focus sul processo di business, non sui dati e la sua struttura. La tua
squadra potrebbe richiedere da 10 a 15 minuti per riscaldarsi, ma segui i passaggi proprio
come li outlinelo qui. Non essere tentato di saltare in avanti.
• Scrivi il nome di ogni evento di Dominio su una nota adesiva. Il nome, come hai imparato
nel capitolo precedente, dovrebbe essere un verbo dichiarato nel passato. Ad esempio,
un evento può essere denominato ProdottoCreato e un altro può essere denominato
BacklogItemCommitted .
 (Si può certamente rompere questi nomi in più righe sulle note adesive.) Se si sta facendo
big-picture storming e si pensa che questi nomi sono troppo precisi per i partecipanti,
utilizzare altri nomi.
• Posizionare le note adesive sulla superficie di modellazione in ordine di tempo, ovvero da
sinistra a destra nell'ordine in cui si verifica ogni evento nel dominio. Si inizia con il primo
Eventi di dominio all'estrema sinistra della superficie di modellazione e quindi spostarsi
gradualmente verso destra. A volte non si avrà una buona comprensione dell'ordine dei
tempi, nel qual caso si dovrebbe solo mettere il corrispondente Eventi di dominio da
qualche parte nel modello. Capire la parte "quando", che probabilmente diventerà
evidente, più tardi.
• Un Evento di dominio che si verifica in parallelo con un altro in base al processo di business
può trovarsi sotto l'evento Evento di dominio di dominio che si verifica contemporaneamente.
Quindi, si utilizza lo spazio verticale per rappresentare l'elaborazione parallela.
• Come si passa attraverso questa parte della sessione di tempesta, si sta andando a trovare
punti problematici nel vostro processo di business esistente o nuovo. Segna chiaramente
questi con una nota adesiva viola / rosso e un po 'di testo che spiega perché è un problema. È
necessario investire tempo in tali punti per saperne di più.
• A volte il risultato di un evento di Dominio è un Processo che deve essere eseguito. Potrebbe
trattarsi di un singolo passaggio o di più passaggi complessi. Ogni Evento di dominio che causa
l'esecuzione di un Processo deve essere catturato e denominato in una nota adesiva lilla.
Disegnare una linea con una freccia dall'evento di dominio A Processo denominato (nota
adesiva lilla). Modella un Evento di dominio con granularità fine solo se è importante per il tuo Dominio
principale. Molto probabilmente un processo di registrazione utente è una necessità, ma probabilmente
non è considerata una caratteristica di base dell'applicazione. Modella il processo di
registrazione come un singolo evento con granularità grossolana, UtenteRegistrato, e vai
avanti. Mettete i vostri sforzi concentrati in eventi più importanti.
Se si ritiene di aver esaurito tutti i possibili eventi di Dominio importanti , potrebbe essere il momento di fare una
pausa e tornare alla sessione di modellazione in un secondo momento. Tornando alla superficie di
modellazione un giorno dopo vi farà senza dubbio trovare concetti mancanti e per affinare o
scacciare quelli superficiali che in precedenza consideravano importanti. Anche così, a un certo
punto avrete identificato la maggior parte degli Dominio eventi di dominio che sono di massima
importanza. A quel punto si dovrebbe passare al passo successivo.
2.Creare i comandi che causano ogni evento di dominio. A volte un Evento di dominio sarà il
risultato di un avvenimento in un altro sistema, e confluirà nel vostro sistema di conseguenza.
Eppure, spesso un Comando sarà il risultato di qualche gesto dell'utente, e che Comando , una
volta effettuata, causerà un Evento di dominio. Le Comando dovrebbe essere indicato
nell'imperativo, come ad esempio Creaprodotto E CommitBacklogItem . Queste sono alcune
linee guida di base:
• Nelle note adesive azzurre, scrivere il nome del comando che causa ogni evento di dominio
corrispondente. Evento di dominio. Ad esempio, se si dispone di un evento di Dominio
denominato BacklogItemCommitted , il comando corrispondente che causa l'evento è
denominato
CommitBacklogItem .
• Posizionare la nota adesiva azzurra del comando appena a sinistra dell'evento di Evento di
dominio Dominio che provoca. Sono associati in coppie: Comando/Evento , Comando/Evento ,
Comando/Evento e così via. Tenere presente che alcuni eventi di dominio si verificheranno a causa
di limiti di tempo raggiunti e pertanto potrebbero non avere un comando corrispondente che li causa
in modo esplicito.
• Se è presente un ruolo utente specifico che esegue un'azione ed è importante
specificare, è possibile inserire una piccola nota adesiva giallo brillante nell'angolo
inferiore sinistro del comando azzurro con una figura di bastone e il nome del ruolo. Nella
figura precedente, "Proprietario prodotto" sarebbe il ruolo che esegue il comando.
• A volte un comando causerà l'esecuzione di un Processo. Potrebbe trattarsi di un singolo
passaggio o di più passaggi complessi. Ogni comando che causa l'esecuzione di un Processo
deve essere catturato e nominato in una nota adesiva lilla. Disegnare una linea con una
freccia dal comando A Processo denominato (nota adesiva lilla). Il Processo causerà
 effettivamente uno o più comandi e i successivi eventi di Dominio e se sai cosa sono ora, crea
Nota adesive per loro e mostra loro che emettono dal Processo.
• Continuare a spostarsi da sinistra a destra nell'ordine di tempo come hai fatto quando si
crea ognuno degli eventi di Dominio.
 • È possibile che la creazione di Comandi vi farà pensare Eventi di dominio (come sopra
quando si scopre il lilla Processi o altre) che in precedenza non è stata immaginata. Vai
avanti e affrontare questa scoperta mettendo il nuovo scoperto Evento di dominio sulla
superficie di modellazione insieme alla corrispondente Comando.
• È inoltre possibile che vi sia un solo comando che causa più eventi di Dominio. Va bene;
modellare il comando e posizionarlo a sinistra dei più eventi di Dominio che provoca.
Dopo aver associato tutti i comandi agli eventi di dominio che causano, è possibile passare al
passaggio successivo.

3.Associare l'entità/aggrega in cui viene eseguito il comando e che produce il risultato

dell'evento di dominio. Si tratta del supporto dati in cui vengono eseguiti i comandi e vengono
generati eventi di Dominio. vengono emessi. Ho diagrammi delle relazioni di entità sono spesso il primo e
più popolare passo nel mondo IT di oggi, ma è un grosso errore iniziare da qui. Gli uomini d'affari
non li capiscono bene e possono chiudere rapidamente le conversazioni. Infatti, questo
passaggio è stato relegato al terzo posto in Evento Storming , perché siamo più concentrati sul
processo di business che sui dati. Anche così, dobbiamo pensare ai dati a un certo punto, e
questo punto è ora. In questa fase, gli esperti aziendali probabilmente capiranno che i dati
entrano in gioco. Di seguito sono riportate alcune linee guida per la modellazione delle
aggregazioni:
 • Se gli uomini d'affari non amano la parola Aggregazione o se li confonde in qualche modo,
dovresti usare un altro nome. Di solito possono capire Entità , o si potrebbe semplicemente
chiamarlo Dati. La cosa importante è che l'adesivo permette al team di comunicare
chiaramente il concetto che rappresenta. Utilizzare le note adesive giallo pallido per tutti
gli aggregati e scrivere il nome di un Aggregazione La tua ogni nota adesiva. Si tratta di un
sostantivi, ad esempio Prodotto Le BacklogItem . Questa operazione verrà esatale per
ogni aggregazione nel modello.
• Posiziona la nota adesiva Aggregata dietro e leggermente sopra le coppie Comando ed
Evento di Aggregazione Evento di dominio dominio. In altre parole, dovresti essere in grado
di leggere il sostantivi scritto nella nota adesiva Aggregata, ma le coppie Comando ed Evento
di Dominio devono rispettare la parte inferiore dell'aggregazione per Aggregazione
indicare che sono associate. Se si vuole davvero mettere un po 'di spazio tra gli adesivi
che va bene, ma basta essere chiari quali comandi ed eventi di Dominio appartengono a
quale aggregazione.
• Quando ci si sposta nella sequenza temporale dei processi aziendali, è probabile che le
aggregazioni vengano utilizzate ripetutamente. Non riorganizzare la sequenza temporale
per spostare tutte le coppie Comando/Evento in una singola nota adesiva aggregata. Invece,
creare lo stesso sostantivi Aggregato su più note adesive e posizionarle ripetutamente sulla
sequenza temporale in cui si verificano le coppie Comando/Evento corrispondenti. Il punto principale è
quello di modellare il processo di business; il processo di business si verifica nel tempo.
• È possibile che, man mano che si pensa ai dati associati alle varie azioni, è possibile che
vengano individuati nuovi eventi di Dominio. Non ignorarli. Posizionare invece gli eventi di
Dominio appena individuati insieme ai comandi e Tutti aggregazioni corrispondenti sulla superficie di
modellazione. Si può anche scoprire che alcuni aggregati Aggregati sono troppo complessi,
ed è necessario suddividere questi in un Processo gestito (lilla appiccicoso). Non ignorare
queste opportunità.
Una volta completata questa parte della fase di progettazione, ci si sta avvicinando ad alcuni
dei passaggi aggiuntivi che è possibile eseguire se si sceglie di. È inoltre possibile tenere presente
che se si utilizza Approvvigionamento eventi , come descritto nel capitolo precedente, si è già
fatto molta strada verso la comprensione dell'implementazione del dominio principale, poiché vi è una grande
sovrapposizione in Storming di eventi e Esempio di evento. Naturalmente, più il tuo storming è
vicino al quadro generale, più potenzialmente è dall'implementazione effettiva. Tuttavia, è
possibile utilizzare questa stessa tecnica per raggiungere una vista a livello di progettazione. Nella
mia esperienza i team tendono a entrare e uscire dal grande design e dal livello di progettazione
all'interno delle stesse sessioni. Alla fine il vostro bisogno di imparare alcuni dettagli vi porterà
oltre il quadro generale per raggiungere un modello a livello di progettazione dove è essenziale.
4.Disegnare contorni e linee con frecce per mostrare il flusso sulla superficie di
modellazione. È molto probabile che ci siano più modelli in gioco e eventi di Dominio che
scorrono tra i modelli, nelle sessioni di Event Storming. Ecco come affrontare questo problema:
• In sintesi, molto probabilmente si troveranno confini nelle seguenti condizioni: divisioni
dipartimentali, quando diversi uomini d'affari hanno definizioni contrastanti per lo
stesso termine, o quando un concetto è importante ma non realmente parte del
dominio principale.
• È possibile utilizzare le penne marker nere per disegnare sulla superficie di
modellazione della carta. Mostra contesto e altri contorni. Utilizzare linee continue per
contesti delimitati e linee tratteggiate per sottodomini. Ovviamente disegnare i confini
sulla carta è permanente, quindi assicurati di capire questo livello di dettaglio prima di
guadare. Se si desidera iniziare delimitando i modelli con meno permanenza, utilizzare
gli adesivi rosa per contrassegnare le aree generali e trattenere i confini del disegno con
indicatori permanenti fino a quando la vostra fiducia lo giustifica.
• Posizionare le note adesive rosa all'interno di vari contorni e inserire il nome che si
applica all'interno del contorno su quelle note adesive. In questo modo i contesti
delimitati.
• Disegnare linee con punte di freccia per mostrare la direzione degli eventi di Dominio
che scorrono tra contesti delimitati. Questo è un modo semplice per comunicare come
alcuni eventi di Dominio arrivano nel sistema senza essere causati da un comando nel contesto
delimitato.
Qualsiasi altro dettaglio su questi passaggi dovrebbe essere intuitivamente ovvio. Basta
usare i confini e le linee per comunicare.
 5.Identificare le varie visualizzazioni necessarie agli utenti per eseguire le azioni e i ruoli
importanti per i vari utenti.
• Non dovrai necessariamente mostrare ogni vista che l'interfaccia utente fornirà, o
qualsiasi altro per quella materia. Se si decide di mostrare le viste, dovrebbero essere
quelle che sono significative e richiedono un po 'di particolare attenzione nella creazione.
Questi artefatti della vista possono essere rappresentati da note adesive verdi sulla
superficie di modellazione. Se è utile, disegnare un mockup rapido (o wireframe) delle
visualizzazioni dell'interfaccia utente che sono più importanti.
• È inoltre possibile utilizzare note adesive giallo brillante per rappresentare vari ruoli utente
importanti. Anche in questo caso, mostra questi solo se hai bisogno di comunicare qualcosa
di significativo circa l'interazione dell'utente con il sistema, o qualcosa che il sistema fa per
un ruolo specifico dell'utente.
Potrebbe essere che il quarto e il quinto passo sono tutti gli extra che dovrai incorporare con
i tuoi esercizi di Storming dell'event.

Altri strumenti
Naturalmente questo non impedisce la sperimentazione, ad esempio il posizionamento di altri disegni
sulla superficie di modellazione e l'esecuzione di altri passaggi di modellazione nella sessione
Storming evento. Ricordate, si tratta di imparare e comunicare un disegno. Usa tutti gli strumenti che
ti servono per modellare come una squadra affiatta. Fai solo attenzione a rifiutare la cerimonia,
perché costerà molto. Ecco alcune altre idee:
Introdurre specifiche eseguibili di alto livello che seguono l'approccio specificato/quando/poi.
Questi sono noti anche come test di accettazione. Potete leggere di più su questo nel libro
Specifica per esempio di Gojko Adzic [Specifica] , e fornisco un esempio nel Capitolo 2 ,"Progettazione
strategica con contesti delimitati e il linguaggio onnipresente ". Basta fare attenzione a non
esadire con questi, dove diventano tutto consumante e hanno la precedenza sul modello di
dominio effettivo. Ritengo che richieda da qualche parte nell'intervallo tra il 15% e il 25% in più di
tempo e fatica per utilizzare e mantenere le specifiche eseguibili invece di comuni approcci basati
su unit test (dimostrati anche nel capitolo 2), ed è facile rimanere coinvolti nel mantenere le specifiche rilevanti
per la direzione aziendale corrente man mano che il modello cambia nel tempo.
 Provare Mappatura dell'impatto [Mapping impatto] per assicurarsi che il software che si sta
progettando sia un Dominio di base e non un modello meno importante. Questa è una tecnica
definita anche da Gojko Adzic.
Esaminare il mapping della storia utente di Jeff Patton [Mapping storia utente] . Questo viene
utilizzato per mettere l'attenzione sul dominio di base e capire quali funzionalità software si dovrebbe investire
Pollici.
I tre strumenti aggiuntivi precedenti hanno una grande sovrapposizione con la filosofia DDD e
sarebbe abbastanza adatto per introdurre in qualsiasi progetto DDD. Tutti loro sono destinati ad
essere utilizzati in un progetto altamente accelerato, sono bassa cerimonia, e sono molto a buon
mercato da usare.

Gestione di DDD in Agile un progettoGestione DDD in un progetto Agile

In precedenza ho detto che c'è stato un movimento intorno a quello che viene chiamato Nessuna
stima. Si tratta di un approccio che rifiuta gli approcci di stima tipici, ad esempio i punti della storia o le ore di
attività. Si concentra sulla fornitura di valore per il controllo dei costi e non stimare qualsiasi
attività che richiederebbe probabilmente solo pochi mesi per completare. Non respingo questo
approccio. Tuttavia, al momento della stesura di questo, i clienti con cui lavoro sono ancora tenuti
a fornire stime e compiti timebox, come lo sforzo di programmazione necessario per
implementare anche funzionalità granulari. Se Nessuna stima funziona per te e la tua situazione di progetto,
usala.
Sono anche consapevole che alcuni nella comunità DDD hanno fondamentalmente definito il
proprio framework di esecuzione di processo o processo per l'utilizzo di DDD e l'esecuzione con
esso su un progetto. Questo può funzionare bene ed essere efficace quando viene accettato da un
determinato team, ma può essere più difficile ottenere buy-in da organizzazioni che hanno già
investito in un framework di esecuzione agile, come Scrum.

Ho osservato che recentemente Scrum è stata sottoposta a notevoli critiche. Anche se non mi
schiero in questa critica, dirò apertamente che spesso o anche la maggior parte delle volte Scrum
viene abusato. Ho già menzionato la tendenza dei team a "progettare" usando quello che io
chiamo "il task-board shuffle". Non è solo il modo in cui Scrum doveva essere utilizzato su un
progetto software. E, per ripetermi ancora una volta, l'acquisizione della conoscenza è sia un tenet
Scrum e un obiettivo importante di DDD, ma è in gran parte ignorato in cambio di consegna implacabile
con Scrum. Anche così, Scrum è ancora molto utilizzato nel nostro settore, e dubito che sarà
spostato in qualsiasi momento presto.
Pertanto, quello che farò qui è mostrarvi come si può fare DDD lavorare in un progetto basato su
Scrum. Le tecniche che vi mostro dovrebbero essere ugualmente applicabili con altri approcci di
progetto agile, ad esempio quando si utilizza Kanban. Non c'è nulla qui che sia esclusivo di Scrum,
anche se alcune delle linee guida sono indicate in termini di Scrum. E dal momento che molti di voi
avranno già familiarità con Scrum mettendolo in pratica in qualche forma, la maggior parte della mia
guida qui sarà per quanto riguarda il modello di dominio
 e l'apprendimento, la sperimentazione e la progettazione con DDD. È necessario cercare
altrove per indicazioni generali sull'utilizzo di Scrum, Kanban o un altro approccio agile.
Dove uso il termine Attività Le bacheca attività , questo dovrebbe essere compatibile con Agile in
generale, e anche Kanban. Dove uso il termine Sprint , cercherò anche di includere le parole
iterazione per agile in generale e Wip (lavori in corso) come riferimento a Kanban. Potrebbe non
essere sempre una misura perfetta, in quanto non sto cercando di definire un processo reale qui.
Spero che si sarà semplicemente beneficiare delle idee e trovare un modo per applicarli in modo
appropriato nel vostro specifico quadro di esecuzione agile.

Le prime cose prima di tutto

Uno dei mezzi più importanti per impiegare con successo DDD in un progetto è quello di assumere
brave persone. Semplicemente non c'è sostituzione per le persone buone, e gli sviluppatori sopra
la media per quella materia. DDD è una filosofia avanzata e tecnica per lo sviluppo di software, e
richiede sviluppatori sopra la media, anche molto buoni sviluppatori, per metterlo in uso. Non
sottovalutare mai l'importanza di assumere le persone giuste con le giuste competenze e auto-
motivazione.

Utilizzare l'analisi SWOT

Nel caso in cui non si abbia familiarità con l'analisi SWOT [SWOT], sta per Punti di forza, punti
di debolezza, opportunità e minacce. L'analisi SWOT è un modo per pensare al tuo progetto in
modi molto specifici, acquisindo la massima conoscenza il prima possibile. Ecco le idee di base
dietro quello che stai cercando di identificare su un progetto:
• Punti di forza: caratteristiche dell'azienda o del progetto che gli danno un vantaggio rispetto
agli altri
• Punti deboli: caratteristiche che pongno l'attività o il progetto in svantaggio rispetto ad altri
• Opportunità: elementi che il progetto potrebbe sfruttare a proprio vantaggio
• Minacce: elementi dell'ambiente che potrebbero causare problemi all'azienda o al progetto
 In qualsiasi momento su qualsiasi Scrum o altro progetto agile dovresti sentirti libero e
incline a utilizzare l'analisi SWOT per determinare la situazione attuale del tuo
progetto:
1. Disegnare una matrice di grandi dimensioni con quattro quadranti.
2. Tornando alle note adesive, scegliere un colore diverso per ciascuno dei quattro quadranti
SWOT.
3.Ora, identità i punti di forza del progetto, i punti deboli del progetto, le opportunità sul
progetto, e le minacce al progetto.
4. Scrivi questi sulle note adesive e posizionale nella matrice all'interno del quadrante
appropriato.
5.Utilizzare queste caratteristiche SWOT del progetto (stiamo pensando in particolare
modello di dominio qui) per pianificare ciò che si sta per fare su di loro. I prossimi passi che
fai per promuovere le buone aree e mitigare le aree problematiche potrebbero essere
fondamentali per il tuo successo.
Avrai la possibilità di inserire queste azioni nella bacheca attività mentre esegui la
pianificazione del progetto, come discusso più avanti.

Picchi di modellazione e modellazione del debito

Ti sorprende sapere che puoi avere picchi di modellazione e debito di modellazione da pagare su
un progetto DDD?
Una delle cose migliori che puoi fare all'inizio di un progetto è usare Storming di eventi . Questo
e gli esperimenti di modellazione correlati costituirebbero un picco di modellazione. Si dovrà
"acquistare" conoscenza circa il vostro prodotto Scrum, e a volte il pagamento è un picco, e un
picco durante l'inizio del progetto è quasi certo. Ancora, vi ho già mostrato come l'utilizzo di
Evento Storming può ridurre notevolmente il costo degli investimenti necessari.
Di certo, non ci si può aspettare di modellare il dominio perfettamente fin dall'inizio, anche se si
pensa in termini di inizio del progetto come avere un picco di modellazione prezioso. Non sarai
nemmeno perfetto mentre usi Storming di eventi . Per prima cosa, il business e la nostra
comprensione di esso cambiano nel tempo, così come il vostro modello di dominio.
 Inoltre, se si intende impostare il tempo di programmazione delle attività come attività in una
bacheca attività, prevedere di incorrere in un debito di modellazione durante ogni sprint (o iterazione
o WIP). Semplicemente non avrai il tempo di svolgere ogni attività di modellazione desiderata alla
perfezione quando sei in timeboxed. Per prima cosa, si inizierà un design e realizzare dopo la
sperimentazione che il design che avete non si adatta alle esigenze aziendali così come ci si aspettava.
Tuttavia, il limite di tempo che si è sotto richiederà di andare avanti.
 La cosa peggiore che potresti fare ora è dimenticare tutto quello che hai imparato dagli sforzi di
modellazione che hanno richiesto un design diverso e migliorato. Piuttosto, prendere nota che
questo deve andare in uno sprint successivo (o iterazione, WIP). Questo può essere portato alla
1
riunione retrospettiva e trasformato in come una nuova attività alla prossima riunione di
pianificazione sprint (o riunione di pianificazione iterazione, o aggiunto alla coda Kanban).
1 . In Kanban si può effettivamente avere retrospettive ogni giorno, quindi non aspettare a lungo per presentare la necessità
di migliorare il modello.

Identificazione delle attività e stima dello sforzo

Storming di eventi è uno strumento che può essere utilizzato in qualsiasi momento, non solo
durante l'inizio del progetto. Quando si lavora Pollici una sessione di Tempesta di eventi, si creerà
naturalmente una serie di elementi. Ognuno degli Dominio eventi di dominio , Comandi e
aggregazioni che si esce nel modello cartaceo può essere utilizzato come unità di stima. Come è così?

Uno dei modi più semplici e precisi per stimare consiste nell'utilizzare un approccio basato sulle
metriche. Come si vede qui, creare una tabella semplice con unità di stima per ogni tipo di
componente che sarà necessario implementare. Questo toglierà le congetture dalle stime e fornirà
la scienza intorno al processo di creazione di stime dello sforzo. Ecco come funziona la tabella:
1.Creare una colonna per Tipo di componente per descrivere il tipo specifico di componente per il quale sono
definite le unità di stima.

2.Creare altre tre colonne, una per Facile , Moderata e Complesso. Queste colonne
rifletteranno l'unità di stima, che è in ore o frazioni di ore, per il tipo di unità specifico.
3.Creare ora una riga per ogni tipo di componente nell'architettura. Le proprietà indicate sono i
tipi Evento di dominio , Comando e Aggregazione. Tuttavia, non limitarti a quelli. Creare una
riga per
 vari componenti dell'interfaccia utente, servizi, persistenza, serializzatori di eventi di dominio e
deserializzatori e così via. È possibile creare una riga per ogni singolo tipo di elemento che
verrà creato nel codice sorgente. (Se, ad esempio, si crea normalmente un Concimionatore di
eventi di dominio e deserializzatore insieme a ogni evento di Dominio come passaggio composito,
assegnare un valore di stima per gli eventi di dominio che riflette la creazione di tutti i componenti insieme in ogni
colonna.)
4.Ora riempi le ore o una frazione di ora necessarie per ogni livello di complessità: facile,
moderato e complesso. Queste stime non solo includono il tempo necessario per
l'implementazione, ma possono anche includere ulteriori sforzi di progettazione e test.
Rendere questi precisi, ed essere realistici.
5.Quando si conoscono le attività degli elementi di backlog (WIP) su cui si lavorerà, ottenere
una metrica per ciascuna delle attività e identificarla chiaramente. È possibile utilizzare un
foglio di calcolo per questo.
6.Sommare tutte le unità di stima per tutti i componenti nello sprint corrente (iterazione o
WIP) e questo diventa la stima totale.
Durante l'esecuzione di ogni sprint (iterazione o WIP), ottimizzare le metriche per riflettere le
ore o le frazioni di ore effettivamente necessarie.
Se si utilizza Scrum e si è arrivati a detestare le stime delle ore, capire che questo approccio è
molto più indulgente e anche molto più preciso. Man mano che impari la tua cadenza, affinerai le
tue metriche di stima per essere più accurate e realistiche. Potrebbe richiedere un paio di sprint
per farlo bene. Anche rendersi conto che come il tempo e l'esperienza progredire, probabilmente
si sintonizzano i numeri più bassi o utilizzare le colonne facile Le moderata più facilmente.
Se si utilizza Kanban e si pensa che le stime siano completamente fallaci e inutili, porsi una
domanda: Come faccio a sapere come determinare un WIP accurato in primo luogo per limitare
correttamente la nostra coda di lavoro? Indipendentemente da ciò che si potrebbe pensare, si sta
ancora stimando lo sforzo coinvolto e sperando che sia corretto. Perché non aggiungere un po 'di
scienza al processo e utilizzare questo approccio di stima semplice e accurato?

Un commento sull'accuratezza
Questo approccio funziona. Su un grande programma aziendale l'organizzazione
richiedeva stime per un progetto grande e complesso all'interno del programma
complessivo. A questo compito sono state assegnate due squadre. In primo luogo c'era
un team di consulenti ad alto costo che ha lavorato con aziende Fortune 500 per stimare
e gestire i progetti. Erano contabili e avevano dottorati ed erano dotati di tutto ciò che
avrebbe intimidito e dare loro il chiaro vantaggio. Il secondo team di architetti e
sviluppatori è stato potenziato con questo processo di stima basato su metriche. Il
progetto era nella gamma di 20 milioni di dollari, e alla fine, quando entrambe le stime
sono arrivate, erano all'interno di circa 200.000 dollari l'uno dall'altro (il team tecnico è
la stima leggermente inferiore). Non male per i tecnici.
Dovrebbe essere possibile ottenere una precisione del 20% sulle stime a lungo
termine e molto meglio nelle stime a breve termine, ad esempio per sprint,
iterazioni e code WIP.
Modellazione timeboxed
Ora che si dispone di stime per ogni tipo di componente, è possibile basare le attività
direttamente al di fuori di tali componenti. È possibile scegliere di mantenere ogni componente
come singola attività con un numero di ore o una frazione di esso, oppure si potrebbe scegliere di
suddividere ulteriormente le attività. Tuttavia, suggerisco di fare attenzione a sopportare i compiti
per essere troppo fini, in modo da non rendere la scheda attività eccessivamente complessa.
Come illustrato in precedenza, potrebbe anche essere meglio combinare tutti i comandi e tutti gli
eventi di dominio usati da una singola attività di aggregazione. in un'unica attività.
Come implementare
Anche con gli elementi identificati da Storming di eventi , non avrai necessariamente tutte le conoscenze necessarie per
lavorare su uno scenario di dominio specifico, una storia e un caso d'uso. Se è necessario un altro utente, assicurarsi di
includere il tempo per un'ulteriore acquisizione delle conoscenze nelle stime. Ma il tempo per
cosa? Ricordiamo che nel capitolo 2 Ti ho introdotto per creare scenari concreti intorno al tuo
modello di dominio. Questo può essere uno dei modi migliori per acquisire conoscenze sul tuo
Dominio principale , al di là di ciò che si può ottenere da Evento Storming. Scenari concreti e Assalto di
eventi sono due strumenti che devono essere utilizzati insieme. Ecco come funziona:
• Eseguire una rapida sessione di Evento Storming , forse solo per un'ora o giù di lì. Vi
accrescirete quasi certamente che è necessario sviluppare scenari più concreti intorno ad
alcune delle vostre scoperte di modellazione rapida.
• Collabora con un esperto di dominio per discutere di uno o più scenari concreti che devono
essere perfezionati. Identifica la modalità di utilizzo del modello software. Anche in questo
caso, queste non sono solo procedure, ma devono essere dichiarate con l'obiettivo di
identificare gli elementi effettivi del modello di dominio (ad esempio, gli oggetti), il modo in
cui gli elementi collaborano e come interagiscono con gli utenti. (Fare riferimento a Capitolo
2 in base alle esigenze).)
• Creare un set di test di accettazione (o specifiche eseguibili) che esercitano ciascuno

degli scenari. (Fare riferimento al capitolo 2 in base alle esigenze.)

• Creare i componenti per consentire l'esecuzione dei test/specifiche. Iterare (brevemente e
rapidamente) come si perfezionano i test / specifiche e i componenti fino a quando non
fanno ciò che il esperto di dominio vostro si aspetta.
• Molto probabilmente una parte dell'iterazione (breve e rapida) indurrà a prendere in
considerazione altri scenari, creare ulteriori test/specifiche e perfezionare i componenti
esistenti e creare nuovi componenti.
Continuare fino a quando non si è acquisita tutte le conoscenze necessarie per soddisfare un
obiettivo aziendale limitato o fino alla scadenza della timebox. Se non hai raggiunto il punto
desiderato, assicurati di incorrere nella modellazione del debito in modo che questo possa
essere affrontato nel (idealmente vicino) futuro.
Ma quanto tempo ti servirà da Esperti di dominio?
Interazione con gli esperti di dominio
Una delle principali sfide dell'utilizzo di DDD è trovare tempo con gli esperti di dominio e senza
esagerare. Molte volte coloro che sono esperti di Dominio si tratta di un progetto avranno un sacco di altre
responsabilità, ore di riunioni, ed eventualmente di viaggio. Con tali potenziali assenze
dall'ambiente di modellazione, può essere difficile trovare abbastanza tempo con loro. Quindi,
faremmo meglio a fare il tempo che usiamo contare e limitarlo a ciò che è necessario. A meno che
tu non renda divertenti ed efficienti le sessioni di modellazione, hai buone possibilità di perdere il
loro aiuto al momento sbagliato. Se lo trovano prezioso, illuminante e gratificante, probabilmente
stabilirai la forte partnership di cui avrai bisogno.
Quindi le prime domande a cui rispondere sono: "Quando abbiamo bisogno di tempo con gli
esperti di dominio ? Quali compiti hanno bisogno per aiutarci a svolgere?"
• Includi sempre esperti di Dominio nelle attività di Storming degli eventi. Gli sviluppatori
avranno sempre un sacco di domande, e gli esperti di dominio avranno le risposte. Assicurati
che si trovino insieme nelle sessioni di Storming di eventi.
• È necessario il contributo degli esperti di dominio sulle discussioni e sulla creazione di scenari di

modello. Per alcuni esempi, vedere il capitolo 2.

• Gli esperti di dominio saranno necessari per esaminare i test per verificare la correttezza del
modello. Questo presuppone che gli sviluppatori hanno già fatto uno sforzo coscienzioso
per aderire al linguaggio Onnipresente e per utilizzare la qualità, dati di test realistici.
• Avrete bisogno di esperti di dominio per perfezionare il linguaggio onnipresente e i suoi nomi
aggregati, comandi ed eventi di dominio , che sono determinati dall'intero team. Le ambiguità
vengono risolte attraverso la revisione, le domande e la discussione. Anche così, le sessioni di
Evento Storming dovrebbero
 hanno già risolto la maggior parte delle domande sulla lingua onnipresente.
Così, ora che sapete che cosa avrete bisogno da esperti di Dominio , quanto tempo si
dovrebbe richiedere di loro per ciascuna di queste responsabilità?
• Le sessioni di Event Storming devono essere limitate a poche ore (due o tre) ciascuna.
Potrebbe essere necessario tenere sessioni in giorni consecutivi, ad esempio per tre o
quattro giorni.
• Bloccare la notevole quantità di tempo per la discussione e il perfezionamento dello
scenario, ma cercare di ottimizzare il tempo per ogni scenario. Si dovrebbe essere in grado
di discutere e iterare su uno scenario per forse 10 a 20 minuti di tempo.
• Per i test, è necessario un po 'di tempo con gli esperti di dominio per rivedere ciò che hai scritto.
Ma non aspettatevi loro di sedersi lì come si scrive il codice. Forse lo faranno, e questo è un
bonus, ma non aspettatelo. Modelli accurati richiedono meno tempo per la revisione e la
verifica. Non sottovalutare la capacità degli esperti di Dominio di leggere un test con il tuo aiuto.
Possono farlo, soprattutto se i dati di test sono realistici. I test devono consentire all'esperto
Esperto di dominio di dominio di comprendere e verificare intorno a un test ogni uno o due
minuti, o giù di lì.
• Durante le revisioni dei test, Esperti di dominio può fornire input Aggregati , Comandi E
Eventi di dominio , e forse altri artefatti, su come aderiscono al Lingua onnipresente.
Questo può essere realizzato in breve quantità di tempo.
Queste linee guida dovrebbero aiutarti a utilizzare la giusta quantità di tempo con gli esperti di
dominio e a limitare il tempo che devi trascorrere con loro.

Riepilogo
In sintesi, in questo capitolo hai imparato:
• Informazioni su Storming di eventi , su come può essere utilizzato e su come eseguire
sessioni con il tuo team, il tutto al fine di accelerare i tuoi sforzi di modellazione
• Informazioni su altri strumenti che possono essere utilizzati insieme a Storming di eventi
• Come utilizzare DDD su un progetto e come gestire le stime e il tempo necessario con
Dominio Esperti
Per un riferimento esaustivo che copre l'implementazione di DDD nei progetti, vedere
Implementazione della progettazione basata il tuo dominio [IDDD] .
Riferimenti

[BDD] Nord, Dan. "Sviluppo basato sul comportamento". 2006.

http://dannorth.net/introducing-bdd/ .

[Causal] Lloyd, Wyatt, Michael J. Freedman, Michael Kaminsky e David G. Andersen. "Non
accontentarti di un'eventuale coerenza: proprietà più forti per l'archiviazione con replica
geografica a bassa latenza."
http://queue.acm.org/detail.cfm?id=2610533 .

[DDD] Evans, Eric. Progettazione basata su domini: affrontare la complessità nel cuore del
software.
Boston: Addison-Wesley, 2004.
[Scrum essenziale] Rubin, Kenneth S. Essential Scrum: una guida pratica all'Agile più popolare
Processo. Boston: Addison-Wesley, 2012.
[IDDD] Vernon, Vaughn. Implementazione della progettazione basata su dominio. Boston:
Addison-Wesley, 2013.

[Mapping impatto] Adzic, Gojko. Mappatura dell'impatto: un grande impatto con i prodotti e i
progetti Software. Procente pensieri, 2012.

[Microservizi] Newman, Sam. Creazione di microservizi. Sebastopol, CA: O'Reilly Media, 2015.

[Reattivo] Vernon, Vaughn. Modelli di messaggistica reattiva con il modello attore: applicazioni e
Integrazione in Scala e Akka. Boston: Addison-Wesley, 2015.
[RiP] Webber, Jim, Savas Parastatidis e Ian Robinson. REST in pratica: Hypermedia e
Architettura dei sistemi. Sebastopol, CA: O'Reilly Media, 2010.
[Specifica] Adzic, Gojko. Specifiche per esempio: come i team di successo consegnano il software giusto.
Manning Publications, 2011.
[SRP] Wikipedia. "Principio di responsabilità unica".
http://en.wikipedia.org/wiki/Single_responsibility_principle .

[SWOT] Wikipedia. "Analisi SWOT."

https://en.wikipedia.org/wiki/SWOT_analysis .

[Mapping storia utente] Patton, Jeff. Mappatura della storia utente: scopri l'intera storia,
costruisci il giusto
Prodotto. Sebastopol, CA: O'Reilly Media, 2014.
[WSJ] Andreessen, Marc. "Perché il software sta mangiando il mondo." Giornale di Wall Street
, 20 agosto 2011.
[Ziobrando] Brandolini, Alberto. “Introducing EventStorming.”
https://leanpub.com/introducing_eventstorming .
Indice

Un
Astrazioni
modellazione aggregati, 93 –95
problemi di progettazione del
software, 5
Strumenti di accelerazione e
gestione
Storming Event, 112 –124
gestione dei progetti DDD. Vedere Gestione di DDD sul progetto Agile
altri utensili, 124
panoramica di, 111 –112
sintesi, 136
Test di accettazione
di DDD su Agile Project, 134
utilizzo con Event Storming, 124
convalida del modello di dominio, 39 –40
Precisione, gestione nel progetto, 130 –131
Modello attore
memorizzazione nella cache dello stato di Aggregate, 109
gestione delle transazioni, 78
utilizzo con DDD, 43
Adattatori, 41 –42
Radice aggregata, definita, 77
Aggregati
associazione con i comandi, 120 –122
scegliendo con attenzione le astrazioni, 93 –95
la mia favita la palla di fango via, 59
progettazione come unità teabili, 97 –98
Esperti di dominio, 134 –136
Eventi di dominio di approvvigionamento per 107 –109 Eventi di dominio
diapprovvigionamento
identificazione dei compiti/sforzo di stima, 129 –131
integrazione tramite messaggistica, 65 –70
modellazione, 88 –93
panoramica, 75
ridimensionamento a destra, 95 –97
scenario con utilizzo, 104 –105
 sintesi, 98
nella progettazione tattica, 8 –9
transazioni e, 78 –81
perché vengono utilizzati, 76 –78
Aggregazioni, regole di progettazione
 eseguire il commit di un'istanza in una
transazione, 79–81 81 proteggere le invarianti
aziendali all'interno dei limiti, 82 riferimento
solo per identità, 84 –85 dimensioni piccole, 83 –
84
aggiornamento con coerenza finale, 85 –88
Contesto di gestione dei progetti Agile
e mappatura del contesto, 52
astrazioni di modellazione per aggregazioni, 93
–5 concetti in movimento in altri contesti
delimitati, 51
Modello di dominio anemico, evitando in aggregati, 88 –
89 , 92 Livello Anticorruzione
Mappatura del contesto, 56 –57
integrandosi con Big Ball of Mud via, 60
nel servizio Host aperto, 57
RPC con SOAP con, 62
Servizi applicativi
Architettura dei contesti delimitati, 42
acgregazione di modelli, 89
Architettura, contesti delimitati, 41 –43
Frecce, in Storming evento, 123
Messaggistica asincrona, 65 –70
Recapito At-Least-Once, modello di messaggistica, 68 –69
Transazioni di database atomici, 78 –79

B
Cattivo design, nello sviluppo di software, 3 –7 Behavior-
Driven Development (BDD), linguaggio onnipresente, 39 Grande
palla di Fango

caso di studio, 21 –24

Mappatura del contesto e, 59 –60
trasformando nuovo software in, 17
l'utilizzo di esperti aziendali per evitare, 18 –
20 utilizzando sottodomini per i sistemi
legacy, 48 –49
Evento di grande immagine Storming, 114
Penne a pennarello nere, per Event Storming, 115 ,
122 –123 Libro Progettazione: Un'introduzione pratica
(Martin), 5 –6 Confini, Aggrega
passaggi di progettazione per il dimensionamento corretto, 95 –97
protezione delle invarianti aziendali entro 82
coerenza transazionale e, 78 –81
Contesti delimitati
 allineamento con singolo sottodominio, 49 –50
componenti architettonici di, 41 –43
caso di studio, 21 –24
disegnare i contorni in Event Storming, 122 –
124 Mapping del contesto tra. Vedere Mappatura
del contesto come strumento di progettazione
strategica fondamentale, 25 –29 politiche di
modellazione aziendali in separate, 20
che mostra il flusso sulla superficie di modellazione in Event Storming, 122 –123
nella progettazione strategica, 7 –8
Sottodomini in. Vedi sottodomini
nella progettazione tattica, 9
team e repository di codice sorgente per, 14
comprensione, 11 –14
Brandolini, Alberto, 112 –113
Azienda
Limiti aggregati che proteggono le invarianti di 82 , 95 –96
Focalidel il tuo esperto di dominio su, 17 –20, 27 –29
Evento Storming focus su, 113
Processo di Storming degli eventi tramite eventi di
dominio, 116 –118 eventuale coerenza guidata da,
97 focus sulla complessità di, 29
logica di perdita durante la modellazione di aggregazioni, 89
progettazione del software rispetto a scopi di, 4 –5
Sottodomini all'interno di domini di, 46
unit test e specifiche di convalida per, 97 –98

C
Memorizzazione nella cache, prestazioni di aggregazione, 109Caching, Aggregate
performance, 109
Coerenza causale, Eventi di dominio per, 99 –
100 Sfida, 29
Reclami, 19 –20 , 70 –73
Classi, 90 –94
Contesto di collaborazione
modelli mentali stimolanti e unificanti, 33
e mappatura del contesto, 52
Messaggio di comando, 67
Separazione di responsabilità delle query di comandi (CQRS),
43 , 109 comandi, Storming di eventi
Associa entità/Aggrega a, 120 –122
causando eventi di dominio, 118 –120
Eventi di dominio vs., 107
 identificazione dei compiti/sforzo di stima, 129 –131
utilizzo di esperti di dominio per perfezionare,
134 –136 Comportamento complesso, modellazione
aggregati, 93 complessità, riduzione della
progettazione basata su dominio, 2 –3
conformisti
Mappatura del contesto, 56
Consumer di eventi di dominio e, 67
nel servizio Host aperto, 57
Errori HTTP RESTful e, 64
Mappatura del contesto
definito, 52
esempio in, 70 –73
fare buon uso di, 60 –61
panoramica di, 51 –53
nello spazio dei problemi, 12
progettazione strategica con, 8
sintesi, 73
utilizzando la messaggistica, 65 –70
utilizzo di RESTful HTTP, 63 –65
utilizzo di RPC con SOAP, 61 –63
Mappatura del contesto, tipi di
Strato di anticorruzione, 56 –57
Grande palla di fango, 59 –60
Conformista 56 anni
Fornitore cliente, 55 –56
Servizio host aperto, 57
Partenariato 54
Lingua pubblicata, 58
Modi separati, 58
Kernel condiviso, 55
Concetti di base
Contesti delimitati per 25 –26
caso di studio, 21 –24
Dominio principale
modelli mentali stimolanti e unificanti da creare, 29 –34
e Mappatura del contesto, 52
affrontare la complessità, 47 –50
definito, 12
sviluppo di un linguaggio onnipresente, 34 –41
Event Sourcing salvataggio record di occorrenze in,
109 Event Storming per capire, 113 –114
 spazio di implementazione dello spazio di
soluzione, 12
come tipo di sottodominio all'interno del progetto, 46 –47
Manutenzione linguistica es., 41
Comprensione 13
Costo
Vantaggi di Event Storming, 113
falsa economia di nessun disegno, 5
progettazione del software rispetto a prezzi accessibili, 4 –5
Potrebbe l'elaborazione, utilizzando con DDD, 43
Servizi accoppiati, progettazione software rispetto a fortemente, 5
CQRS (Command Query Responsibility Segregation), 43 ,
109 Mappatura del contesto cliente-fornitore, 55 –56

D
Database
transazioni atomiche, 78 –79
progettazione del software e, 4 –5
DDD Complessità (Domain-
Driven Design) di, 2 –3
un design buono, cattivo ed efficace, 3 –7
processo di apprendimento e la raffinazione
delle conoscenze, 9 –10 gestione. Vedere
Gestione di DDD nel progetto AgileManaging
DDD on Agile Project Panoramica Di 1 –2
progettazione
strategica, 7 –8
progettazione
tattica, 8 –9
Operazione DELETE, RESTful HTTP, 63 –65
Modellazione a livello di progettazione, Event Storming, 114
Diagrammi, 36
Eventi di dominio
Esempio di mapping del contesto, 70 –73
creazione dell'interfaccia, 101
arricchimento con dati aggiuntivi, 104
Evento Sourcing e, 107 –109
l'asincrono con REST, 65
nella messaggistica, 65 –70
tipi di denominazione di, 101 –102
 proprietà, 103 –104
scenario di utilizzo, 104 –107
riepilogo, 109 –110
in progettazione tattica, 9 , 99 –100
Eventi di dominio, Storming di eventi
 associare Entity/Aggregate al comando, 120 –
122 create Commands che causano, 118 –120
creazione per il processo di business, 116 –
118 identificazione di attività/sforzo di stima,
129 –131 identificazione visualizzazioni/ruoli
per gli utenti, 123 –124 che mostra il flusso sulla
superficie di modellazione, 122 –123 utilizzando gli
esperti di dominio per perfezionare, 134 –136

Esperti di dominio
driver di business e, 17 –20
sviluppare un linguaggio onnipresente come
scenari, 35 –41 concentrarsi sulla complessità
aziendale, 28
identificando i concetti di base, 26 –29
implementa il progetto DDD su Agile, 133 –
134 interagendo con, 134 –136
astrazioni di modellazione per aggregazioni,
93 –95 per uno o più sottodomini, 46
in rapida progettazione. Guardia l'storming degli eventi
dimensionamento a destra Aggrega, 95 –96
Scrum 27
nella progettazione strategica, 7 –8

E
Progettazione efficace, 6 –7
Sforzo, stima per Agile Project, 129 –131
Arricchimento, Evento di dominio, 71 –72
Entità
Aggregati composti da, 77
associazione con i comandi, 120 –122
definito, 76
implementazione di progettazione aggregata, 90 –91
Dimensionamento a destra Aggrega, 95
Oggetti di valore che descrivono/quantificano, 77
Stime
gestione delle attività in Agile Project, 129 –131
Modellazione timeboxing delle attività tramite,
132 –134 Architettura basata su eventi, con DDD, 42 ,
112 –113 Evento Sourcing
 nelle transazioni di database atomici, 78 –79
sovrapposizioni tra Evento Storming e, 121 –122
eventi di dominio persistenti per le aggregazioni,
107 –109
Storming di eventi
 vantaggi di, 113 –114
associare Entity/Aggregate al comando, 120 –
122 comandi che causano eventi di Dominio 118 –120
scenari concreti, 35

Eventi di dominio per il processo aziendale,

116 –118 Esperti di dominio per 134 modelli basati su
eventi rispetto a 112 –113
identificare le attività/stimare lo sforzo, 129 –131
identificare visualizzazioni/ruoli per gli utenti, 123 –124
Distribuzione di progetti DDD su Agile, 133 –134
picchi di modellazione sui progetti DDD tramite, 129
altri strumenti utilizzati con, 124
mostrare il flusso sulla superficie di modellazione, 122 –123
forniture necessarie per 115 –116
Eventi, in Event Storming, 113 , 115
Coerenza finale
dimensionamento a destra Aggrega, 97
l'aggiornamento delle aggregazioni, 85 –88
con cui lavorare, 88
lavorare con scenari, 38

F
Programmazione funzionale, modellazione di aggregati, 89

G
Sottodominio generico, 47
Operazione GET
Esempio di mapping del contesto, 72
integrazione con RESTful HTTP, 63 –65 A
livello globale identità univoca, progettazione
aggregata, 90 –91 Buona progettazione,
sviluppo software, 3 –7

Ho
Officina IDDD, 3
Ricevitore idempotente, messaggistica, 68
Mappatura dell'impatto, 124
Implementazione della progettazione basata su dominio ( IDDD), Vaughn, 1 , 3
Adattatori di input, architettura contesti delimitati, 42
Politica di ispezioni, 19 –20
Iterazioni
l'accuratezza delle stime a lungo termine per 131
identificazione dei compiti/sforzo di stima, 130
 di DDD su Agile Project, 134
incorrere nel ricorrere al debito di modellazione durante, 128 –129
come sprint, 126

K
Conoscenza 9 –10
Acquisizione della conoscenza, 4 –5 , 6

L
Lingua
evoluzione della terminologia nell'uomo, 15
Onnipresente. Vedi Lingua Oniquito
Latenza
nello scambio di messaggi, 65
Errori HTTP RESTful dovuti a, 64
Processo di apprendimento, raffinazione delle conoscenze in, 9 –10
Sistemi legacy, che utilizzano sottodomini con, 47 –50

M
Fase di manutenzione, linguaggio onnipresente,
40 –41 Gestione di Gestione dDD su progetto
Agile
precisione e, 130 –131
Storming Event, 112 –124
assumere brave persone, 126
come implementare, 133 –134
identificazione dei compiti/sforzo di stima, 129 –131
interagendo con gli esperti di dominio, 134 –136
picchi di modellazione/debito, 128 –129
altri utensili, 124
panoramica di 125 –126
sintesi, 136
modellazione a tempo, 132 –134
utilizzando l'analisi SWOT, 127 –128
Martin, Douglas, 5 –6
Footprint di memoria, progettazione di
aggregati di piccole dimensioni, 83 messaggi,
65 –70
Approccio basato sulle metriche, identificazione delle
attività/sforzo stimato, 129 –131 Microservizi, utilizzando
With DDD, 43 Modellazione

debito e picchi sui progetti DDD, 128 –129

sviluppo delle strade e, 6
 panoramica di, 1
Moduli, segregazione sottodomini in, 50

N
Denominazione
di aggregati, 91 –92
di tipi di evento di dominio, 101 –102
Esperti di dominio che raffinano aggregato,
134 –136 Entità radice di aggregazione, 78
Provider di rete, errori HTTP RESTful dovuti a, 64
Nessun disegno o modello, falsa economia di, 5
Approccio alle stime, 125
Sostantivi, in lingua onnipresente, 34 –36

Le
Programmazione orientata agli oggetti, Aggregazioni, 88
–89 , 91 –92 Servizio Host aperto
utilizzo della lingua pubblicata, 58
Mappatura del contesto, 57
RESTful HTTP con, 63
RPC con SOAP con, 62
Opportunità, identificazione del progetto Agile, 127
–128 adattatori di output, architettura dei contesti
delimitati, 42

P
Documento, conduzione di Evento Storming, 115 –116
Elaborazione parallela, Storming di eventi del processo
aziendale, 117 Mappatura del contesto di partenariato, 54
Prestazioni, memorizzazione nella cache e
snapshot per, 109 Operazioni di persistenza,
progettazione software vs., 5 Archivio di
persistenza, Aggregazioni per identità per, 85
immagini, nello sviluppo di modelli di dominio, 36
criteri
gruppo di imprese, 18 –20
Esempio di mappatura del contesto di 70 –73
segregazione in contesti delimitati, 20
Porte, utilizzo con DDD, 41 –42
Operazione POST, RESTful HTTP, 63 –65
Spazio del problema
Contesti delimitati in, 12
Vantaggi di Event Storming per 114
panoramica di, 12
 utilizzo di sottodomini per la
discussione, 47
Processo, Evento Storming del business, 117
Proprietario del prodotto, Scrum, 27 , 119
Proprietà, Evento di dominio, 103 –104
Lingua pubblicata
in mappatura del contesto, 58
integrando contesti delimitati tramite, 67
RESTful HTTP con, 63
RPC con SOAP con, 62
Funzionamento PUT, RESTful HTTP, 63 –65

D
Compromessi di Query-back, Eventi di dominio, 71 –72

R
Design rapido. Vedere Storming di eventi
Modello reattivo, utilizzando con DDD, 43
Riferimento per identità solo, Aggregati, 84 –85 I
riferimenti, usati in questo libro, 137 –138
Chiamate di procedura remota (RPC) con SOAP, 61 –
63 Trasferimento di stato rappresentativo (REST), 43
, 65 comunicazioni Request-Response, messaggistica, 69
–70 REST in Pratica (RIP), 63 –65
REST (Trasferimento dello stato
rappresentativo), 43 , 65 RESTful HTTP, 63 –
65 , 72 Strade, modellazione di, 6
Robustezza, RPC carente, 62
Ruoli, identificazione per gli utenti in Event Storming,
123 –124 Entità radice, Aggregazione
definito, 78
implementazione di progettazione aggregata, 90 –91
ridimensionamento a destra, 95
RPC (chiamate di procedura remota) con SOAP, 61 –63

S (in vi
Scenari
lo sviluppo di un linguaggio onnipresente
come, 35 –38 progetto DDD su Agile, 133 –
 134 Esperti di dominio: parte dell'opinione Pollici 134 –
136 mettendo al lavoro, 38 –40
Scrum
 critiche a 125 –126
DDD Esperto di dominio contro proprietario
del prodotto in, 27 buona, cattiva ed
efficace progettazione in, 3 –7
gestione del progetto. Vedere Gestione di DDD sul progetto Agile
Limiti contestuali semantici, contesti delimitati,
mapping del contesto in 12 modi separati, 58
architettura orientata ai servizi (SOA), 43 servizi, servizio Host
aperto, 57
Mapping del contesto del kernel condiviso, 55
protocollo SOAP (Simple Object Access Protocol), RPC con, 61
–63 Principio di responsabilità unica (SRP), Aggregati, 84
Dimensione. Vedere Contorni, Aggregazione
Snapshot, di prestazioni aggregate, 109
SOA (Architettura orientata ai servizi), 43
SOAP (Simple Object Access Protocol), con, 61 –63 sviluppatori
di software
sviluppo di un linguaggio onnipresente come
scenari, 35 –41 Esperti di dominio contro, 26 –29
trovare bene, 126

progettazione rapida per. Guardia l'storming degli eventi

Spazio soluzione
Contesti delimitati utilizzati in 12
panoramica di, 12
segregazione sottodominio in, 50
Repository di codice sorgente, per contesti
delimitati, 14 specifiche (Adzic), 124
Specifiche per esempio, perfezionamento del linguaggio
onnipresente, 39 Sprint
l'accuratezza delle stime a lungo termine per 131
identificazione dei compiti/sforzo di stima, 130
incorrere nel ricorrere al debito di modellazione durante, 128 –129
SRP (Principio di responsabilità unica), Aggregati, 84
Parti interessate, progettazione software vs., 4 –5
Note adesive, Storming dell'evento
associare Entity/Aggregate al comando, 121 –122
creare comandi che causano eventi di Dominio 118 –120
definiti, 113
Eventi di dominio per il processo di business,
116 –117 identificare i ruoli per gli utenti,
124 panoramica di, 115 –116
che mostra il flusso sulla superficie di modellazione, 123
 Archiviazione, riferimento ad Aggregazioni per
identità per 85 Progettazione strategica
componenti architettonici, 41 –43
Contesti delimitati in, 11 –17
caso di studio, 21 –24
presupposti/modelli mentali unificanti, 29– 34 con
Contesto Mapping. Vedere Mappatura del contesto
Esperti di dominio e driver di business in, 17 –
20 attenzione alla complessità aziendale, 28
necessità fondamentale per, 25 –29
con Sottodomini. Vedi Sottodomini
Riepilogo 43
Lingua onnipresente in, 11 –17 , 34 –41
comprensione, 7 –8
Punti di forza, identificazione di Agile Project, 127 –128
Sottodomini
per la complessità, 47 –50
panoramica di, 45 –46
che mostra il flusso in Event Storming, 122 –123
progettazione strategica con, 7 –8
Riepilogo 50
tipi di, 46 –47
comprensione, 46
Forniture, per Event Storming, 115 –116
Dominio di supporto, 47 , 50
Analisi SWOT (Forze, Punti deboli, opportunità e minacce), Progetti Agile, 127 –128

T
Progettazione tattica
con Aggregazioni. Vedi Aggregazioni
con gli eventi di dominio. Vedere Eventi di dominio
comprensione, 8 –9
Taskboard shuffle
stime/uso del progetto di, 5
progettazione del software vs., 3 –4
tendenza a progettare utilizzando, 126
Attività
identificazione/stima in Agile Project, 129 –
131 timeboxed modeling di, 132 –133
Squadre
assegnazione a ogni contesto delimitato, 14
 Rapporto conformista tra, 56
Integrazione del contesto, 53
Relazione cliente-fornitore tra 55 –56
Vantaggi di Event Storming per, 113 –114
Relazione di partenariato tra, 54
Relazione del kernel condiviso tra, 55
Ubiquitous Lingua parlata entro, 13 –14
Tecnologia
Mappatura del contesto integrata, 53
mantenere il modello di dominio libero da, 42
modelli di aggregazioni, 90
progettazione del software vs., 4 –5
Test
a vantaggio dei contesti delimitati, 25
Progettazione di Aggregrates per 97 –98
di DDD su Agile Project, 134
utilizzando esperti di dominio in, 136
convalida del modello di dominio, 39 –40
Minacce, identificazione agile Project, 127 –128
Controllo sequenza temporale, Scrum per, 4 –5
Limite di coerenza transazionale, Aggregazioni, 78 –81
Transazioni, Aggregazioni, 78 –81 , 83 –84

U
Lingua onnipresente
s'eruzione dell'evento Storming, 113
in Anticorruption Layer Context Mapping relazione, 56 –57
modelli mentali impegnativi / unificanti da creare, 29 –34
nella mappatura del contesto conformista di
relazione, 56 per ogni dominio principale, 46
–47 in via di sviluppo, 34 –41
sviluppo tramite un ciclo di feedback
collaborativo, 29 come strumento di
progettazione strategica fondamentale, 25 –
29 fase di manutenzione di, 40 –41
astrazioni di modellazione per Aggregazioni,
93 –95 modellazione aggregati, 93
denominazione dei tipi di evento di dominio, 101 –102
nella progettazione strategica, 7
 Comprensione 11 , 13 –14
utilizzo di esperti di dominio per perfezionare, 134 –136
Lingue ubiquitous
 integrando diversi, 53
Mappatura del contesto per modi separati e, 58
traduzione con le lingue pubblicate, 58
UML (Unified Modeling Language), 90 , 112 –
113 Sistemi legacy ilbounded, complessità di, 48
Underwriting, esempio di mapping del contesto, 70 –73 Criteri
di sottoscrizione, 19 –20 Unità Test 40 , 97 –98

Aggiornamenti, Aggregazione, 85 –88 , 96 –97

Interfaccia utente, astrazioni per
aggregazioni, ruolo utente 94, Storming di
eventi, 119
Mappatura della storia utente, Storming di eventi, 124
Storia utente di Mappatura (Patton), 124

Presso
Oggetti valore e aggregazioni, 77 , 91
visualizzazioni, per gli utenti in Event
Storming, 123 –124

W
Muro, conducendo evento Storming su, 115
Punti deboli, identificazione di Agile Project, 127 –128
Problemi con Whack-a-mole, Grande Palla di Fango, 59
Chi? nello sviluppo di Ubiquitous Language, 36 –
38 Lavori in corso (WIP)
l'accuratezza delle stime a lungo termine per 131
identificazione dei compiti/sforzo di stima, 130
incorrendo nel modellare il debito durante, 128 –129
sprint come, 126
Frammenti di codiceCode Snippets