DDD: Come dividere l'applicazione in contesti limitati oltre all'esempio di e-commerce?

Question

Abbiamo una domanda piuttosto grande qui e sto considerando di refactoring un po 'per seguire la guida di ragazzi DDD.

Per ora il problema numero uno con esso è Contesti limitati e Mappe di contesto. Forse non lo faccio, ma mi sembra impossibile fare una divisione. Ad esempio, abbiamo un oggetto User dappertutto ed è esattamente lo stesso oggetto User: nome, ID e ruoli visualizzati. C'è un altro esempio: abbiamo oggetto CatalogItem per aiutarci a categorizzare un'altra entità ovunque. Dobbiamo introdurre le dipendenze del Contesto Limitato? C'è qualche indicazione su questo argomento oltre a quel noioso campione di e-commerce?

Answer 1

Ho scoperto che, inizialmente, contesti e radici aggregate sembravano il concetto più semplice in DDD. Questo fino a quando non arriverai ad implementare un'applicazione DDD con un problema del mondo reale. Non c'è una risposta facile qui. Dipende totalmente dai requisiti aziendali (scalabilità, disponibilità, latenza, coerenza, ecc.). La soluzione "corretta" è quella che bilancia queste preoccupazioni per soddisfare al meglio le tue necessità.

Con l'esempio che si dà, ci sono alcune scelte:

• un unico grande contesto limitato
• separati contesti limitati, con i dati duplicati (eventualmente implementato utilizzando un publish/sistema di messaggistica iscriviti)
• Tirare Utenti e CatalogItems nel proprio contesto limitato e avere altri contesti limitati accedervi tramite un servizio

Una cosa da tenere a mente è che queryi I bisogni sono spesso molto diversi dai bisogni di "scrittura". Spesso può semplificare la progettazione dell'applicazione in modo da avere contesti separati separati esclusivamente per l'esecuzione di query. Se questo sembra possa essere applicato, guarda in CQRS.