Come definire chiaramente i confini di un contesto limitato

Dopo circa un mese dalla lettura e dalla ricerca di DDD, ho deciso di iniziare il mio progetto e ho creato DDD con questi contesti limitati>

• clienti
• Prodotti
• Ordini
• Fatturazione

Ogni contesto limitato ha API di riposo come livello di presentazione, livello di dominio, livello persistente.

Fin qui tutto bene, il codice funziona senza intoppi, ma proviene da un mondo monolitico, sto ancora cercando di capire quanto segue:

• quando voglio creare un nuovo cliente, emettere una nuova fattura, creare un nuovo ordine, ad esempio, voglio accedere all'elenco dei paesi. Devo:

a) creare un elenco di paesi in ciascun BC

b) creare un paesi BC -> API e utilizzarlo per ottenere un elenco di paesi disponibili

c) utilizzare un'API di terze parti e estrarre i dati tramite il livello anticorruzione in ciascun BC

• quando si integra con API di terze parti utilizzando un livello anti-corruzione o un livello adattatore, quali dati devono essere inclusi nel mio modello di dominio? Ad esempio, se voglio integrare un'API zendesk con un client BC. Ho bisogno solo di un ticketID nel mio dominio o devo estrarre tutti i dati da Zendesk a cui voglio accedere e utilizzare in un client BC?

Se la mia app MVC sta effettivamente ottenendo dati dalle API (livelli di presentazione dei miei contesti limitati) trovo molto difficile definire chiaramente i confini di ciascun BC. Significa che un BC progettato correttamente servirebbe un singolo controller MVC senza la necessità di consumare API aggiuntive?

Se i tuoi diversi contesti limitati comprendono in modo diverso il significato / lo scopo di un paese, allora devi modellarlo in modo appropriato in ciascuno di essi. Tuttavia, se stiamo semplicemente parlando di dati di riferimento di codici e nomi ISO, credo che sia abbastanza giusto e standard nasconderlo 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 pezzi che hai elencato potrebbero benissimo essere "entità" in un "contesto limitato", a seconda della struttura dell'azienda. Le BC spesso finiscono per essere definite intorno a diverse aree / dipartimenti / squadre, poiché questo è spesso il confine naturale tra "linguaggi onnipresenti". Quindi, ad esempio, invece di Vendite / Prodotti / Ordini, mi aspetto che i BC siano sulla falsariga di Vendite / Produzione / Magazzinaggio.

All'interno di quei BC, non ti concentri sui nomi. Ti concentri sui casi d'uso e crei modelli dei nomi in grado di soddisfare i casi d'uso. I metodi su una "radice aggregata" eseguono casi d'uso e apportano le modifiche appropriate ai modelli correlati.

... tutti i modelli sono sbagliati, ma alcuni sono utili.

Ricorda inoltre che ogni BC può usare un sistema o un'architettura completamente diversi. Un dato BC potrebbe non meritare affatto l'uso di "componenti software DDD", e molti di loro probabilmente no. DDD riguarda meno i componenti software prescrittivi e più il processo di progettazione del software. Il punto è concentrarsi sulla comprensione dei contesti limitati dell'azienda, sulla mappatura dei linguaggi onnipresenti di ogni contesto e sulla modellizzazione del codice per quel contesto usando il loro linguaggio onnipresente. In questo modo quando interagisci con i portatori di interessi e fai riferimento al codice, suona come se stessi parlando in termini commerciali che comprendono. E riconoscere che la stessa parola ha significati diversi in diversi BC.

Esistono schemi specifici prodotti da DDD (ad es. Repository, stratificazione specifica, ecc.) Che sono mezzi per raggiungere un fine. Ma questi schemi non sono garantiti per essere i modelli migliori 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 fraintenda il contesto limitato. Puoi rileggere il capitolo 14 del libro blu .

Cercando di rispondere in generale - devi stare attento a condividere concetti tra due diversi contesti limitati. Dopotutto, parte della ragione per cui esiste il confine è che il linguaggio onnipresente cambia. Presumere che gli stessi dati (e la stessa rappresentazione) di un'entità possano essere usati in entrambi i contesti è ingenuo: può essere giusto, può 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 di tariffe e simili.

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

Cosa dovrebbe succedere nei tuoi modelli di dominio quando un paese è occupato da una potenza straniera?

Tieni a mente; molti di noi sono abituati a pensare alla struttura dei dati; qual è la relazione tra un dato e l'altro. Ed è fantastico quando si considerano i report e si cerca di assicurarsi 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 anche la tua attenzione su quella parte e assicurarti di capire bene come i dati vincolano le modifiche (e come tali vincoli variano da un contesto limitato a quello successivo).

I concetti menzionati (clienti, prodotti, ordini, fatturazione) sono generalmente rappresentati in un singolo modello di dominio e quindi in un contesto limitato. Ti suggerisco di capire questi concetti in modo errato.

La mia opinione su questo argomento è definire un contesto limitato usando una mappatura delle capacità aziendali o altre tecniche simili come l'analisi della catena del valore. Si riduce ai seguenti passaggi:

1. Definire le responsabilità di livello superiore del sistema o le capacità aziendali. Penso che il modo migliore per farlo sia evocare i passi che la tua impresa attraversa per ottenere un valore aziendale. I confini logici che ti vengono in mente sono i tuoi servizi aziendali o, se vuoi, i contesti limitati.
2. Approfondisci ogni servizio.
3. Identifica le comunicazioni tra i tuoi servizi insieme ai primi due punti.

Quindi l'attenzione iniziale è su come opera la tua azienda.

Coppia di consigli pratici:

1. Se uno dei tuoi contesti / servizi / etc necessita di alcuni dati di altri contesti, molto probabilmente i tuoi confini sono sbagliati.
2. Il modo altamente auspicabile di comunicazione contestuale è basato sugli eventi. Questa è una chiave per la scalabilità e l'affidabilità. Se hai bisogno di 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 è alla fine più coerente di quanto pensi. Proprio come tutti gli altri. Non cercare di rendere tutto coerente al 100%. Non ha senso pratico in questo.
4. I contesti non devono essere orchestrati. Sono autonomi. Come gli umani.

Con questo approccio si ottengono servizi altamente autonomi, gestibili e affidabili. Potresti voler controllare un esempio di definizione dei confini del contesto.