Cosa, in riferimento a DDD, è un contesto limitato?

Contesti e sottodomini limitati esistono a diversi livelli.

Un sottodominio è una parte dello spazio del problema, è un partizionamento naturale del sistema, che spesso riflette la struttura dell'organizzazione. Le operazioni logistiche e potrebbero essere separate dalla fatturazione e amp; fatturazione . Eric differenzia i sottodomini core , che supportano e generici in base alla loro rilevanza commerciale in uno scenario specifico.

Contesti sono parti dello spazio delle soluzioni. Sono modelli . Sarebbe una buona cosa averli, riflettere i partizionamenti dei sottodomini ... ma la vita non è sempre così facile. E potresti avere un dominio legacy ingombrante che include tutto, o più contesto nello stesso sottodominio (cioè la vecchia app legacy l'app sostitutiva che qualcuno sta costruendo).

Per avere un Contesto Limitato devi avere un modello e un confine esplicito attorno ad esso. Esattamente ciò che manca in molte applicazioni basate sui dati che utilizzano database per condividere dati.

Un altro - ortogonale - modo per vederlo potrebbe essere il seguente. Lingua onnipresente , la condizione speciale in cui ogni termine ha un'unica definizione univoca, non scala. Più lo si ingrandisce, più si insinua l'ambiguità. Se si desidera ottenere modelli precisi e non ambigui, è necessario esplicitare i propri confini e parlare molte piccole lingue Ubiquitous, ciascuna all'interno di un singolo Contesto Limitato, con uno scopo ben definito. .

Le tecniche di Domain Driven Design sono utilizzate per aiutarci a creare modelli del mondo in cui viviamo. Questi modelli esistono come idee nelle menti delle persone coinvolte in un progetto.

Poiché la telepatia è ancora agli inizi, queste idee vengono comunicate tra le persone usando parole e frasi.

Le parole e le frasi possono essere ambigue nel migliore dei casi. Per aiutarci a ridurre l'ambiguità, utilizziamo il "contesto" per chiarirne il significato.

Quando le persone si immergono profondamente in un progetto software che abbraccia anni, sembrano dimenticare il contesto da cui sono nate le idee che sono diventate le parole che hanno trasformato i nomi delle variabili che sono stati inseriti nel codice.

I neofiti arrivano al progetto e iniziano a usare e a consumare il suo linguaggio. Forse sono utenti, forse sono sviluppatori. Se non viene fornito loro un contesto, verranno fuori con il proprio contesto (e, quindi, il significato) dalla propria esperienza di vita.

Questo contesto appena applicato guiderà il modo in cui i nuovi sviluppatori refactoring o sviluppare il codice. Se hanno applicato il contesto sbagliato, si rifatteranno e svilupperanno il codice, forse sempre così leggermente, nella direzione sbagliata. Le indicazioni sbagliate, per quanto leggere, possono causare problemi molto più grandi lungo la linea.

Per come la vedo io, un "contesto limitato" è semplicemente un "contesto chiarito" che viene consegnato ai neofiti del progetto in modo che non applichino il proprio contesto arbitrario per contaminare il nostro modello meravigliosamente levigato.

È un riconoscimento esplicito, da parte del team, che this phrase , in this part of the project significa esattamente this thing (e non, come potresti ben pensare, that thing ).

Proprio come è una buona idea segnare i confini tra il tuo giardino e il giardino del tuo vicino. Devi specificare il confine esplicitamente in modo da non arrabbiarti quando iniziano a scavare un'aiuola sul tuo prato perfettamente curato.

È così. È un'idea molto semplice che è così importante che ne è stato scritto un sacco.

Quindi sì. Un contesto limitato è letteralmente un confine, un "recinto", che distingue tra il contesto di un sottodominio dal contesto di un altro sottodominio in un progetto.

Il modello e la lingua di un sottodominio sono isolati da altri modelli e linguaggi per evitare ambiguità di significato.

Ma sì. Il mondo non è così semplice.

Tu e il team dovete essere rigorosi nell'aderire al contesto definito. È davvero facile essere pigri e re-immaginare il contesto per tagliare gli angoli durante la costruzione del software.

Inoltre, le cose interagiscono con altre cose e contesti limitati devono interagire tra loro. Quindi, ci sono vari modelli per descrivere come avvengono queste interazioni. Vedi il capitolo 14 del libro Domain Driven Design di Eric Evan per questi diversi modelli: kernel condiviso, fornitore del cliente, conformista, livello anticorruzione, modi separati, servizio host aperto, lingua pubblicata.

Fondamentalmente, il contesto Limitato definisce alcuni limiti tangibili dell'applicabilità di alcuni sottodomini. È un'area astratta in cui un determinato sottodominio ha senso, mentre gli altri no. Quindi questo può essere un discorso, una presentazione, un progetto di codice con limiti fisici definiti dall'artefatto.

In diverse situazioni uso tre diverse prospettive, o metafore del concetto di Contesto Limitato.

Dal punto di vista dell'esecuzione, rappresenta i limiti logici, definiti dal contratto di un servizio in cui è implementato il modello. Il contratto può essere rappresentato come l'API di questo servizio o un insieme di eventi che pubblica e consuma. Quindi da questa prospettiva il contesto limitato non ha nulla a che fare con i confini fisici.

Dal punto di vista di un esperto di domini, il contesto limitato è un'area in cui sono implementati determinati processi aziendali, viene applicato un determinato linguaggio ubiquitario e un certo significato è chiaro, mentre gli altri no. Quindi è solo un rettangolo disegnato su un foglio di carta o una lavagna.

Per uno sviluppatore di software, ad esempio, dal punto di vista del codice statico, un contesto limitato rappresenta un modo in cui ho progettato i miei modelli attorno ai sottodomini corrispondenti. Con quante basi di codice viene implementato un sottodominio specifico? In cosa consistono i concetti? Quali concetti sono applicabili a ciascuno di essi? Ecco perché si dice che i contesti limitati appartengono a uno spazio di soluzione.

Mi piace molto questo esempio del Concetto di contesto limitato.

Un'altra domanda importante (se non la più importante) è come identificare i contesti limitati . Se lo fai in modo errato, finirai con chiacchierone, non mantenibile e servizi strettamente accoppiati , noto anche come monolite distribuito .