È normale che un modello di dominio non abbia un ID?

Question

È normale che un modello di dominio non abbia un ID?

#1 da (7 voti)

2

Dopo aver letto il libro; Ho capito quanto segue:

1) Le entità dovrebbero implementare l'uguaglianza e confrontare per ID. 2) Gli oggetti valore dovrebbero implementare l'uguaglianza e confrontare tutte le proprietà nella classe.

Credo ancora che la mia comprensione del secondo punto sia corretta. Tuttavia, sono confuso circa il punto uno a causa di quanto segue:

1) Questo blogger parla della creazione di una classe base di entità, che tutte le entità ereditano da: link . Pertanto tutte le entità implementano l'uguaglianza per ID perché i confronti di uguaglianza sono definiti nella classe base.

2) La maggior parte delle classi di entità qui ha ID: link

3) Questa domanda sembra suggerire di avere un attributo ID: ID proprietà sugli oggetti Dominio in DDD

4) Questa domanda rimanda a un video di YouTube (punto uno) in cui si sostiene che le entità non dovrebbero avere ID.

I punti 1-4 sopra sembrano suggerire: 1) utilizzare un ID di database; 2) utilizzare un altro ID che non sia l'ID del database; 3) Usa nessun ID.

Sto cercando di decidere se:

1) Avere una superclasse di entità.

o 2) Avere un ID (dal database) in ogni entità.

o 3) Introdurre un identificatore (non l'ID del database) che identifica gli oggetti del dominio.

Sto cercando di isolare completamente il modello di dominio (ho anche un modello di dati).

c# domain-driven-design entity

posta w0051977 07.02.2018 - 16:47

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design entity

Suggerimenti per la progettazione: come progettare una lezione di wrap Iniezione delle dipendenze e contenitore DI

score 7 · Accepted Answer

Per definizione, entità hanno un'identità.

Questo fatto, di per sé, non implica che tu debba avere una proprietà Id sui tuoi oggetti entità. Se non hai mai bisogno di fare riferimento o confrontare l'entità al di fuori del tuo aggregato, non ce n'è davvero bisogno.

Di solito, tuttavia, ha senso che ogni entità abbia un ID. Da dove viene l'ID? A meno che tu non abbia una ragione specifica per fare diversamente, preferirei che l'applicazione crei l'ID, non il database. Puoi utilizzare gli UUID ( Guid in C #) o alcuni IdGenerator personalizzati. Il fatto che il database possa utilizzare il valore Id come chiave è puramente casuale per quanto riguarda il modello di dominio.

Questo lascia la domanda della classe base Entity . Ci sono alcuni motivi per cui potresti non volerne uno:

Entity non è un concetto di dominio, quindi avere gli oggetti di dominio che dipendono da esso non è l'ideale.

Si potrebbe obiettare che Id non è nemmeno un concetto di dominio. Motivi pratici per introdurlo a parte, direi che l'identità è un interesse implicito del dominio - altrimenti potresti semplicemente usare oggetti valore.
Il Entity avrà pochissime funzionalità. Ereditare da esso solo per avere una proprietà Id , ed eventualmente un controllo di uguaglianza di una riga molto stabile ( this.Id == other.Id ) sembra eccessivo.

Detto questo, penso che sia molto improbabile che ti imbatti in problemi dovuti alla classe base Entity . Quindi, se ti aiuta a concentrarti sulla logica del dominio (ad esempio, non permettendoti di dimenticare di sovrascrivere Equals , nel caso in cui questo è il modo in cui intendi implementare il controllo di uguaglianza), con tutti i mezzi provaci.