DDD: Come lavorare con le variazioni dell'entità?

Question

DDD: Come lavorare con le variazioni dell'entità?

#1 da (3 voti)

4

Diciamo che ho un'entità che rappresenta un dipendente:

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender
    .... (and so on)

Ora, immagina di avere un sito web con 2 pagine: una home page e una pagina del profilo.

Sulla home page, ci sarà il nome e il sesso degli ultimi 10 impiegati registrati. In questo modo:

David (male)
Frank (male)
Anna (female)
Bob (male)
Lynda (female)

Quando faccio clic sul nome di un dipendente, verrò indirizzato alla pagina del profilo che mi mostrerà tutti i dati del dipendente selezionato

Poiché ho solo bisogno dei loro nomi sulla home page, non ha senso caricare l'intero modello dal database (non ho bisogno del loro genere, colore dei capelli, ecc ..., solo i nomi. se l'entità dipendente ha molti più dati).

Come gestisco questa situazione in DDD? Non sembra che questo sia un problema di contesto limitato. Devo creare diverse varianti dell'entità? Ad esempio:

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender

LastEmployee
    First name
    Gender

domain-driven-design domain-model entity

posta hendoe 08.05.2018 - 07:07

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design domain-model entity

Come implementare l'algoritmo di commesso viaggiatore con dipendenze tra posizioni Contravarianza degli argomenti, scopo e uso del mondo reale?

score 3 · Accepted Answer

Il problema è che, in generale, in qualsiasi progetto di applicazione, esistono due tipi di modelli: un modello di scrittura e uno o più modelli di lettura. Il classico stile di architettura dell'applicazione unisce i due tipi di modelli in uno e ciò porta a problemi nell'implementazione dei modelli.

La soluzione è CQRS, più esattamente per pensare in CQRS , cioè, quando si pensa ai modelli esistenti, si immagina un modello di scrittura (il modello responsabile delle mutazioni di stato) e uno o più modelli letti (i modelli responsabili della lettura / visualizzazione / visualizzazione dello stato).

Le architetture CQRS complete hanno database diversi per i due tipi di modelli, ma non è necessario andare così lontano. È possibile avere un modello di scrittura, ovvero un aggregato in termini DDD per l'impiegato e due modelli di lettura per i due casi d'uso: EmployeeDetails e LastEmployee . Se non si utilizzano eventi di dominio per mantenere i due modelli letti in sincronia con il modello di scrittura, è possibile utilizzare lo stesso database / tabella per i modelli di scrittura e lettura ma disporre di servizi diversi per il recupero dei dati.

Quindi puoi avere:

EmployeeRepository class per Employee Aggregate, con metodi di caricamento / salvataggio,
ListOfEmployeeDetails class per il modello di lettura EmployeeDetails , con metodi di ricerca / caricamento e,
ListOfLastEmployee class per LastEmployee , con metodi find / load,

tutte queste classi che accedono alla stessa tabella / raccolta del database.

Si noti che non si tratta di CQRS al 100%, ma di un'applicazione simile a CQRS.