Posso darti un altro esempio. Considera che hai un sistema di e-commerce. Ci sarebbero prodotti lì, tuttavia i prodotti faranno parte di almeno due domini diversi:
- Catalogo prodotti, dove mantieni la descrizione del prodotto e tutti gli attributi
- Spazio pubblicitario, in cui è disponibile il livello di scorte del prodotto
Se hai un contesto limitato per entrambi i domini, la tua soluzione può rapidamente diventare una grossa palla di fango perché inizierai a farvi riferimento. Alla fine non avrai più due domini. L'inventario del tuo prodotto sarà rovinato dai riferimenti al catalogo del prodotto e viceversa. Come risultato di ciò, non sarai in grado di cambiare un dominio senza toccarne un altro, anche se ti rendi pienamente conto che non è necessario. I tuoi modelli diventano dipendenti gli uni dagli altri e strettamente accoppiati e dipendenti in modo cattivo, dipendendo dall'implementazione.
Se, tuttavia, hai due contesti limitati, tutte le modifiche che fai in un dominio non influenzeranno l'altra non appena manterrai i canali di comunicazione liberi. Ciò significa che è necessario disporre della duplicazione dei dati, ma questo è il costo minimo da pagare per l'applicazione basata su componenti accoppiati. I tuoi domini possono parlare tra loro usando eventi di dominio. Anche se non hai intenzione di avere un'applicazione basata su SOA all'inizio, sarai in grado di scalare fino a quel livello quando ne hai bisogno con uno sforzo relativamente basso dato che cambi il trasporto per gli eventi del tuo dominio, lasciando intatta l'idea.
Aggiornamento:
C'è una buona abilità su SkillsMatter, di Eric Evans. Dà un'analogia della vecchia storia, quando diversi ciechi descrivono un elefante dalla loro prospettiva. Poiché ogni uomo può toccare solo una parte dell'elefante, lo descrivono come un "albero", "muro", "serpente", "corda". E ognuno di questi uomini ha ragione nel loro contesto. Il contesto limitato è il luogo in cui vive il linguaggio ubiquo. Al di fuori del contesto, questi termini potrebbero avere un significato completamente diverso ma all'interno del contesto, la lingua è la stessa su più domini. Greg Young suggerisce vivamente di iniziare a leggere il libro blu dal capitolo 11, poiché qui vengono spiegati i concetti fondamentali più importanti. L'attenzione ai modelli tattici all'inizio del libro rende questo approccio "DDD-light" molto comune, quando le persone smettono di leggere da qualche parte intorno al capitolo 8 e perdono le cose principali, che sono in qualche modo sepolte nella seconda parte.