Come definire chiaramente i confini di un contesto limitato

Se i diversi contesti limitati comprendono il significato / lo scopo di un paese in modo diverso, allora è necessario modellarlo in modo appropriato in ognuno di essi. Tuttavia, se stiamo parlando semplicemente di dati di riferimento di codici e nomi ISO, ritengo sia piuttosto giusto e standard conservarlo ovunque sia conveniente e renderlo accessibile a tutte le parti interessate. Ad esempio: un database, un file di configurazione, un servizio web, ecc.

Volevo anche guardare un po 'il tuo modello. I brani che hai elencato potrebbero benissimo essere "entità" in un "contesto limitato", a seconda della struttura dell'azienda. Le BC spesso finiscono per essere definite attorno a diverse aree / dipartimenti / gruppi, poiché questo è spesso il confine naturale tra "lingue ubiquitarie". Ad esempio, al posto di Vendite / Prodotti / Ordini, mi aspetto che i BC siano sulla falsariga di Vendite / Produzione / Magazzino.

Dentro quei BC, non ti concentri sui nomi. Ti concentri sui casi d'uso e crei modelli dei nomi che possono soddisfare i casi d'uso. I metodi su una "radice aggregata" eseguono i casi d'uso e apporta le modifiche appropriate ai modelli correlati.

... all models are wrong, but some are useful.

Ricorda inoltre che ogni BC può utilizzare un sistema o un'architettura completamente diversi. Un dato BC potrebbe non meritare affatto l'uso di "componenti software DDD", e la maggior parte di essi probabilmente no. DDD è meno sui componenti software prescrittivi e altro sul processo di progettazione del software. Il punto è concentrarsi sulla comprensione dei contesti limitati dell'azienda, mappare le lingue ubiquitarie di ciascun contesto e modellare il codice per quel contesto usando il loro linguaggio ubiquitario. In questo modo quando interagisci con gli stakeholder e fai riferimento al codice, suona loro come se stessi parlando in termini commerciali che capiscono. E riconoscendo che la stessa parola ha significati diversi in diversi BC.

Esistono modelli specifici portati avanti da DDD (ad es. repository, stratificazione specifica, ecc.) che sono mezzi per un fine. Ma questi modelli non sono garantiti per essere i migliori modelli per ogni caso, anche all'interno di DDD. Proprio come DDD non è la "risposta" per ogni progetto. Devi solo fare ciò che la tua analisi suggerisce è la cosa più pratica da fare.

Dalle tue domande, penso che tu abbia frainteso il contesto limitato. Puoi rileggere il Capitolo 14 del libro blu .

Cercando di rispondere in generale - devi stare attento a condividere i concetti tra due diversi contesti limitati. Dopotutto, parte del motivo per cui esiste il confine è che il linguaggio onnipresente cambia. Assumere che gli stessi dati (e la stessa rappresentazione) di un'entità possano essere usati in entrambi i contesti è ingenuo - potrebbe essere giusto, potrebbe essere sbagliato, ma non c'è un buon modo per quelli di noi all'esterno, senza accesso ai tuoi esperti di dominio, per giudicare.

Ad esempio, nel dominio del cliente, "Paese" potrebbe essere correlato alla residenza o alla cittadinanza. Nella fatturazione, potrebbe essere correlato ai tassi di cambio. In alcuni di questi domini, potresti doverti preoccupare delle tariffe e simili.

Una seconda domanda che devi sollevare è quale dei tuoi modelli è il libro dei record per i dati "condivisi". Nel caso di "paese", la risposta giusta è probabilmente che nessuno di loro è! La topologia geopolitica non è controllata dal tuo modello.

Che cosa dovrebbe accadere nei tuoi modelli di dominio quando un paese è occupato da una potenza straniera?

Ricorda; molti di noi sono abituati a pensare alla struttura dei dati; qual è la relazione tra un dato e un altro. Ed è fantastico quando si stanno prendendo in considerazione i report e si sta tentando di garantire che tutti i dati necessari siano stati raccolti dalla soluzione. Ma i modelli di dominio non riguardano solo la struttura, ma il cambiamento. Devi porre la tua attenzione anche su quella parte e assicurarti di comprendere bene in che modo i dati vincolano le modifiche (e in che modo tali vincoli variano da un contesto limitato al successivo).

I concetti che menzioni (Clienti, Prodotti, Ordini, Fatturazione) sono tipicamente rappresentati in un singolo Modello di Dominio e quindi in Contesto Limitato. Ti suggerisco di capire questi concetti in modo errato.

La mia opinione su questo argomento è definire contesto limitato utilizzando una mappatura aziendale o altre tecniche simili come l'analisi della catena del valore. Si passa ai seguenti passaggi:

1. Definisci le responsabilità di livello superiore del tuo sistema o le capacità aziendali. Il modo migliore per farlo credo è quello di evocare i passaggi che la tua azienda attraversa per ottenere un valore aziendale. I confini logici che ottieni sono i tuoi servizi aziendali, o, se ti piace, contesti limitati.
2. Esamina più a fondo all'interno di ciascun servizio.
3. Identifica le comunicazioni tra i tuoi servizi insieme ai primi due punti.

Quindi l'attenzione iniziale è sul modo in cui opera la tua attività.

Un paio di consigli pratici:

1. Se uno dei tuoi contesti / servizi / etc ha bisogno di altri dati di contesto, molto probabilmente i tuoi limiti sono errati.
2. Il modo altamente auspicabile per la comunicazione di contesto è basato sugli eventi. Questa è una chiave per la scalabilità e l'affidabilità. Se hai bisogno di una comunicazione sincrona, molto probabilmente i tuoi limiti sono sbagliati, di nuovo. Oltre a ciò, la comunicazione sincrona ucciderà il tuo sistema.
3. Il tuo dominio è più coerente alla fine di quanto pensi. Proprio come tutti gli altri. Non cercare di rendere tutto al 100% coerente. Non ha senso pratico in questo.
4. I contesti non devono essere orchestrati. Sono autonomi. Come gli umani.

Con questo approccio ti ritroverai con servizi altamente autonomi, manutenibili e affidabili. Potresti voler controllare un esempio di definizione dei limiti di contesto .