DDD Contesti e domini limitati?

Ho lavorato in un'applicazione relativamente complessa con decine di tabelle di database (aggregati, entità / oggetti valore) e applicando DDD. A questo punto sembra fondamentalmente DDD-Lite che significa che ci sono servizi applicazione / dominio, il modello di dominio (entità, oggetti valore) e repository.

Ho preso un libro sull'implementazione di DDD e la prima cosa che sta menzionando è DDD-Lite e Contesti contrapposti ed eventi di dominio mancanti come primi errori che sono usuali quando si inizia DDD.

Attualmente ho provato a organizzare il modello di dominio in base alle relazioni aggregate e ad usare gli spazi dei nomi per dimostrarlo.

Non riesco a vedere i vantaggi / i fallimenti relativi alla separazione del progetto del modello di dominio in contesti separati (ancora). Forse diventerà evidente in seguito, ma mi piacerebbe un feedback sulla vita reale su contesti limitati (e possibilmente sottodomini ecc. Se si legano a esso).

Prendi in considerazione un'azienda che ha diversi dipartimenti:

• Sviluppo software
• HR
• Contabilità

Sei in grado di elaborare un modello utente in grado di rappresentare espressamente tutte quelle aree di attività? Pensa a come potrebbe essere l'entità Utente in ognuna. Forse è diviso in tre diverse entità:

• Sviluppatore
• Dipendente
• Beneficiario

Lo sforzo di creare un'istanza di un utente in ciascun contesto è notevolmente diverso. Forse è qualcosa del genere:

• nuovo Dipendente (nome, cognome, data di nascita, sesso)
• nuovo sviluppatore (dipendente, workstation, credenziali)
• nuovo beneficiario (dipendente, ruolo)

scusa l'esempio, è difficile illustrare con precisione senza un modello di dominio adeguato a cui fare riferimento

Se si utilizza un'implementazione ingenua e si utilizza una singola entità utente, si tratterebbe di un modello di dati anemico pieno di getter e setter, perché non si può rappresentare completamente l'utente dappertutto.

Ci sono confini chiari nel business, quindi è utile modellarli in quel modo. Un utente che accede contro un utente in un sistema di gestione stipendi rispetto a un utente che gioca una partita sono tutti molto diversi, anche se fanno parte dello stesso grande sistema.

Pensando in un altro modo: ora puoi creare il tuo codice di gestione degli sviluppatori per essere molto leggero e indipendente dal resto del tuo sistema. Può usare tipi più precisi con meno bagagli di cui preoccuparsi. È il passo verso la creazione di sottosistemi più piccoli che possono eventualmente essere estratti nella propria applicazione.

Posso darti un altro esempio. Considera di avere un sistema di e-commerce. Avresti prodotti lì, tuttavia i prodotti faranno parte di almeno due domini diversi:

• Catalogo prodotti, in cui conservi la descrizione del prodotto e tutti gli attributi
• Inventario, in cui si dispone di un livello di scorte di prodotto

Se hai un contesto limitato per entrambi i domini, la tua soluzione può rapidamente trasformarsi in una grande palla di fango perché inizierai a fare riferimenti incrociati. Alla fine non avrai più due domini. L'inventario dei prodotti sarà rovinato con i riferimenti del catalogo prodotti e viceversa. Di conseguenza, non sarai in grado di cambiare un dominio senza toccarne un altro, anche se ti rendi completamente conto che non è necessario. I tuoi modelli diventano dipendenti l'uno dall'altro, strettamente accoppiati e dipendenti in modo negativo - dipendono dall'implementazione.

Se, tuttavia, hai due contesti limitati, tutte le modifiche apportate in un dominio non influiranno sull'altro non appena manterrai chiari i tuoi canali di comunicazione. Significa che devi avere la duplicazione dei dati, ma questo è il costo minimo da pagare per un'applicazione basata su componenti accoppiati in modo errato. I tuoi domini possono dialogare tra loro utilizzando eventi di dominio. Anche se non prevedi di avere un'applicazione basata su SOA all'inizio, sarai in grado di scalare fino a quel livello quando ne avrai bisogno con uno sforzo relativamente basso poiché cambi semplicemente il trasporto per i tuoi eventi di dominio, lasciando intatta l'idea dietro di essa.

Aggiornamento: c'è un buon servizio di abilità su SkillsMatter, di Eric Evans. Fa un'analogia con la vecchia storia, quando diversi ciechi descrivono un elefante dalla loro prospettiva. Poiché ogni uomo può toccare solo una parte dell'elefante, lo descrivono come "albero", "muro", "serpente", "corda". E ciascuno di quegli uomini ha ragione nel loro contesto. Il contesto limitato è il luogo in cui vive un linguaggio onnipresente. Al di fuori del contesto, questi termini potrebbero avere un significato completamente diverso ma all'interno del contesto, la lingua è la stessa in più domini. Greg Young suggerisce vivamente di iniziare a leggere il libro blu dal capitolo 11, poiché qui vengono spiegati i concetti più importanti e fondamentali. L'attenzione ai modelli tattici all'inizio del libro rende molto comune questo approccio alla "luce DDD",