Informazioni su DDD quando si utilizza un ORM come Hibernate

Question

Informazioni su DDD quando si utilizza un ORM come Hibernate

#1 da (3 voti)

2

Ho letto su Domain Driven Design and Anemic models.

Generalmente lavoro con un ORM come Hibernate e sto cercando di capire in DDD cosa può o non può fare un modello di business.

Ad esempio, se ho un oggetto Cliente, dovrei passare questo a una classe di servizio in modo da mantenerlo nel database poiché non è consigliabile iniettare le classi ORM (repository) nel modello di dominio , Sto bene con questo.

Il problema arriva quando voglio verificare che un oggetto Cliente sia valido, alcuni consigliano che l'oggetto Cliente deve saperlo, ma per sapere che ha bisogno di interrogare la tua origine dati per verificare la presenza di altri clienti corrispondenti (ad es. via email indirizzo).

Sembra che il comportamento debba essere sull'oggetto Cliente stesso, ma cosa fai quando il comportamento richiede dati dal database? Passi questo comportamento a una classe del servizio di dominio?

EDIT:

Oppure, per dirla in un altro modo, diciamo che abbiamo un cliente e un film, sull'oggetto cliente abbiamo un comportamento watch (film). Esiste una regola aziendale che stabilisce che un cliente può solo guardare un nuovo film al mese. Metterei una regola nel metodo dell'orologio (film) per gestirlo. Il problema è che l'oggetto Cliente dovrebbe accedere all'origine dati per ottenere un elenco di tutti i film che l'utente ha guardato, determinare quanti sono stati guardati e anche verificare se il film corrente è uno di loro, e se così lo consente da guardare visto che non è un nuovo film per il cliente, come lo farebbe?

a) quando crei l'oggetto Cliente, crei proprietà per archiviare un elenco di film visti questo mese b) creare una classe di servizio per gestire questa regola in modo che possa interrogare l'origine dati al volo piuttosto che avere i dati guidati con entusiasmo?

Con l'opzione a), sarei preoccupato di gonfiore per l'oggetto del cliente, i dati richiesti solo per un singolo caso d'uso specifico, e mi sembra ragionevole prendere solo i dati richiesti quando è effettivamente necessario.

Questa è una situazione ipotetica, sto cercando di capire come applicare la progettazione basata sul dominio.

domain-driven-design

posta SheppardDigital 23.09.2018 - 13:18

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Un negozio può ottenere un punteggio di 12 su Joel Test ma essere tutt'altro che Agile (o Lean)? Un approccio per inviare i contenuti di un file sul server al client in tempo reale

score 3 · Accepted Answer

La tua comprensione del problema in termini di DDD viene offuscata dal tuo focus sul tuo modello di dati (database) invece del comportamento del sistema (dominio).

Per ribadire, lo scopo di DDD è quello di modellare il comportamento di un sistema in modo tale che il risultato sia un'utile astrazione dei suoi requisiti funzionali. Quanto sopra significa che un dominio progettato correttamente è modellato in base al comportamento del sistema, non ai dati. L'unico grande ostacolo che gli sviluppatori incontrano quando si imbarcano in DDD è iniziare utilizzando un modello di dati come modello di dominio, poiché i dati non sono quasi mai un buon punto di partenza quando si tenta di modellare i requisiti funzionali di un sistema.

Che cosa significa sopra? Significa che devi tagliare il tuo modello di dati verticalmente in base al comportamento. In termini pratici, significa che è improbabile che ci sarà un'entità di dominio denominata Customer . Il motivo è perché Customer non denota molto comportamento e probabilmente contiene troppa conoscenza. Cosa fa il tuo Customers ? Comprare cose? %codice%. Guarda le cose (questa è per te)? %codice%. Gestisci un account web? %codice%. Hai un'idea.

Il punto è che le proprietà delle suddette entità di dominio non necessariamente mappano direttamente a una singola tabella di database (e in alcuni casi usano campi della stessa tabella). Ogni Buyer potrebbe avere una raccolta del precedente Viewer . Ogni AccountManager ha una raccolta di Buyer contenente dettagli come OrderReceipts , Viewer , Screenings , MovieId , ecc per ogni volta che guardano qualcosa. E Location potrebbe avere Datetime e DeviceId . E TUTTI i precedenti potrebbero avere lo stesso AccountManager .

La cosa più importante da comprendere sulle entità di cui sopra è che ognuna rappresenta l'unica e non ambigua autorità responsabile della protezione degli invarianti che possono applicarsi ai dati per cui detiene. Segui questa regola e sei d'oro.

Nel tuo caso, un Username è solo un aggregato responsabile della protezione delle tue regole di visualizzazione. Contiene solo i dati aggiuntivi necessari per applicare le regole aziendali. In questo caso una raccolta di oggetti Password del valore dell'ultimo mese (o forse anche meno dati CustomerId ). Ha senso?