Cos'è, in riferimento a DDD, un contesto limitato?

Durante la lettura del libro "Implementing Domain Driven Design" di Vaughn Vernon, non sono stato in grado di ottenere una buona comprensione di cosa sia effettivamente un contesto limitato.

Il libro definisce un contesto limitato come "un confine concettuale in cui è applicabile un modello di dominio. Fornisce il linguaggio Ubiquitous che è parlato dal team ed espresso nel suo modello software accuratamente progettato" (la sezione di prefazione "Guida a questo libro"). Questa definizione farebbe sembrare che un contesto limitato sia il modello e la lingua di un sottodominio, in cui quel sottodominio può essere il dominio principale (che sembra che dovrebbe essere definito come un "sottodominio principale", ma che è un'altra discussione ...). Questo lascia ancora qualche ambiguità su ciò che fornisce un contesto limitato. È un raggruppamento di uno o più sottodomini? Se solo un sottodominio corrisponde a un contesto limitato, cosa ci dice effettivamente il contesto limitato?

Il capitolo 3 dello stesso libro, tuttavia, si riferisce alle tecniche di integrazione tra contesti limitati. Ciò, tuttavia, sembrerebbe implicare che i contesti limitati siano in realtà sistemi software o artefatti di una certa varietà.

Martin Fowler discute brevemente l'idea di un contesto limitato ( http://martinfowler.com/bliki/BoundedContext.html ), ma non chiarisce realmente il problema.

Alla fine della giornata, quello che è un contesto limitato? È un raggruppamento di sottodomini? Il modello e la lingua per un sottodominio? L'implementazione di un sottodominio? Senza queste risposte, sembra piuttosto difficile capire come scomporre uno spazio problematico della vita reale in contesti limitati.

Contesti e sottodomini limitati esistono a diversi livelli.

Un sottodominio è una parte dello spazio problematico, è un partizionamento naturale del sistema, che spesso riflette la struttura dell'organizzazione. Pertanto, la logistica e le operazioni potrebbero essere separate dalla fatturazione e dalla fatturazione . Eric differenzia i sottodomini core , di supporto e generici in base alla loro rilevanza commerciale in un determinato scenario.

I contesti sono parti dello spazio delle soluzioni. Sono modelli . Sarebbe una buona cosa averli, riflettere il partizionamento domini-sottodomini ... ma la vita non è sempre così facile. E potresti avere un dominio legacy gonfiato che comprende tutto, o più contesto nello stesso sottodominio (ovvero vecchia app legacy che l'app di sostituzione che qualcuno sta costruendo).

Per avere un contesto limitato è necessario disporre di un modello e di un confine esplicito attorno ad esso. Cosa manca esattamente in molte applicazioni basate sui dati che utilizzano database per condividere i dati.

Un altro modo - ortogonale - di vederlo potrebbe essere il seguente. La lingua ubiquitaria , la condizione speciale in cui ogni termine ha un'unica definizione non ambigua, non si ridimensiona. Più lo ingrandisci, più si insinua l'ambiguità. Se vuoi ottenere modelli precisi e inequivocabili, devi rendere espliciti i loro confini e parlare molte piccole lingue turbinose, ognuna all'interno di un singolo contesto limitato, con uno scopo ben definito .

Le tecniche di Domain Driven Design vengono 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à, usiamo il 'contesto' per chiarire il loro significato.

Quando le persone si immergono profondamente in un progetto software che si estende per anni, sembrano dimenticare il contesto da cui provengono le idee che si sono trasformate in parole che si sono trasformate in nomi di variabili che sono stati inseriti nel codice.

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

Questo contesto appena applicato guiderà il modo in cui i nuovi sviluppatori effettuano il refactoring o sviluppano il codice. Se hanno applicato il contesto sbagliato, rifletteranno e svilupperanno il codice nella direzione, forse sempre leggermente, sbagliata. Indicazioni errate, per quanto lievi, possono causare problemi molto più grandi lungo la linea.

A mio modo di vedere, un "contesto limitato" è semplicemente un "contesto chiarito" che viene consegnato ai neofiti in modo che non applichino il loro contesto arbitrario per contaminare il nostro modello meravigliosamente raffinato.

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

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

Questo è tutto. È un'idea molto semplice che è così importante che ne sono state scritte molte.

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

Il modello e il linguaggio di un sottodominio sono isolati da altri modelli e linguaggi per evitare ambiguità nel significato.

Ma si. Il mondo non è così semplice.

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

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

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

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

Dal punto di vista del runtime, 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 questo punto di vista il contesto limitato non ha nulla a che fare con i confini fisici.

Dal punto di vista di un esperto di dominio, il contesto limitato è un'area in cui vengono implementati determinati processi aziendali, viene applicato un certo linguaggio onnipresente e alcuni termini hanno un senso chiaro, mentre gli altri no. Quindi è solo un rettangolo disegnato su un foglio di carta o una lavagna.

Per uno sviluppatore di software, ovvero dal punto di vista del codice statico, un contesto limitato rappresenta un modo in cui ho progettato i miei modelli attorno a sottodomini corrispondenti. Con quante basi di codice viene implementato un sottodominio specifico? In quali concetti sono composti? Quali concetti sono applicabili in ciascuno di essi? Ecco perché si dice che i contesti limitati appartengano allo spazio della Soluzione.

Mi piace molto questo esempio del concetto di contesto limitato.

Un'altra domanda importante (se non la più importante) è come identificare contesti limitati . Se lo faresti in modo errato, finirai con servizi chiacchieroni, non mantenibili e strettamente accoppiati , noti anche come monoliti distribuiti .