Un punto disegnato su una tela è considerato un'entità nella progettazione guidata dal dominio?

Sembrava a prima vista una risposta molto ovvia. Ma le cose più ovvie sono a volte le più difficili da spiegare: -)

Prendiamo il tuo esempio di software di disegno. Supponi di avere due forme: un cerchio rosso (C) e una linea blu (L) che si interseca e immagina che Point abbia un'identità determinata in modo univoco dalle sue coordinate:

• Innanzitutto considera che Point non ha altri attributi oltre alle sue coordinate:

  Se non ci sono altri attributi e le coordinate sono l'identità, allora non c'è continuità dell'identità, perché qualunque cosa tu cambi su un Punto, perdi l'identità.
  

• Quindi, prendi uno dei due punti di intersezione di (C) e (L) e chiamalo M :

  L'identità di M dovrebbe definire gli altri attributi di Point come ad esempio Color . Ma quale sarebbe il Color di M unico: rosso perché (C) è stato disegnato per primo? blu perché il (L) è stato estratto per ultimo? viola perché è l'aggiunta di rosso e blu? O il colore associato al punto dipende dalla forma in cui consideri il punto? Nel primo caso, il punto sembra avere un'identità indistinta. Nel caso successivo il punto avrebbe diverse identità (l'id richiederebbe più delle coordinate).
  

• Quindi, diamo una seconda occhiata alla continuità dell'identità:

  Il cerchio rosso ha la sua identità: è definito dal suo nome, (C) . E accanto al suo centro e raggio, è anche composto da un insieme di punti che soddisfano una relazione matematica. Cosa succede se spostiamo (C) ? La sua identità non è cambiata, quindi è lo stesso cerchio, solo con un altro centro. Poiché è lo stesso cerchio e i suoi punti hanno un'identità, e dato che abbiamo una relazione intero / parziale ci aspetteremmo di mantenere lo stesso insieme di punti e spostarli semplicemente, non dovremmo? Ma ogni punto che muoviamo perde la sua identità!
  

Tutto questo ci mostra che se i punti avessero un'identità, avremmo un paio di contraddizioni e incongruenze (o almeno situazioni contro-intuitive). Questo è il motivo per cui i punti dovrebbero essere considerati come oggetti valore in questo esempio. Ecco le definizioni:

ENTITY An object fundamentally defined not by its attributes, but by a thread of continuity and identity.

VALUE OBJECT An object that describes some characteristic or attribute but carries no concept of identity.

-- Eric Evans

Un'entità ha un concetto di identità che è indipendente dal suo valore.

Per il concetto di Point , sono due oggetti punto separati Point(x: 1, y: 2) e Point(x: 1, y: 2) considerati uguali?

• Se sono entità , i punti potrebbero avere identità diverse e sarebbero quindi diversi.
• In pratica, è probabile che un punto sia identificato dalle sue coordinate. I due punti sarebbero quindi uguali. Il punto è un tipo di valore , non un'entità.

Ora potremmo usare una rappresentazione diversa. I punti non contengono la coordinata, ma sono memorizzati in una particolare coordinata, ad es. %codice%. Gli oggetti in due punti sono raster[1][2] = Point() e Point() considerati uguali?

• Ogni istanza punto potrebbe ora rappresentare una coordinata diversa, quindi potrebbero essere diverse.
• Se fossero tipi di valore, sarebbero tutti uguali perché sono vuoti.

Quindi, se un concetto è modellato come entità o tipo di valore dipende dal contesto e talvolta dal resto del modello.

Le entità hanno spesso un ID (sintetico) per tenerne traccia. All'interno di un linguaggio di programmazione questa potrebbe essere la posizione di memoria dell'oggetto, ma questo è solo un identificatore transitorio. Più spesso, viene generato un ID esplicito, ad esempio da utilizzare come chiave primaria in un database, sebbene il concetto di "entità" del database sia leggermente diverso.

Dipende dal tuo modello.

Supponiamo che l'applicazione di disegno sia come MS Paint. Quindi avresti un documento, essendo una bitmap. I pixel nella bitmap sono colorati in base alle azioni dell'utente. Non ci sono oggetti punto, c'è solo una bitmap che cambia mentre l'utente esegue le sue azioni di pittura.

Ora supponiamo che l'applicazione di disegno sia come Scribble. Potresti non sapere Scribble, nel testo scarabocchiato il documento è una serie di tratti. Un colpo consiste in una serie di punti.

Nel secondo modello avrai punti "oggetti". Sebbene si desideri implementarli come tipi di valore, si terranno traccia dei singoli punti e questi verranno memorizzati come punti, i punti saranno (de) serializzati. Punti di tratti diversi possono avere coordinate identiche, tuttavia saranno diversi oggetti individuali.

Nel modello Paint, la posizione della penna potrebbe essere un oggetto, mentre il pixel colorato potrebbe non essere presentato da un oggetto. Tutto dipende dal contesto (chi se ne importa di quell'oggetto, avrebbe uno scopo?). Puoi riconoscere un oggetto in ogni dettaglio, ma a un certo punto dovresti smettere di modellare perché il tuo problema è risolto e spingendo ulteriormente il design OO non serve più a uno scopo. Potrebbe quindi anche peggiorare l'applicazione a causa dell'eccessivo utilizzo delle risorse o dei problemi di prestazioni introdotti.

È possibile "identificare" oggetti valore con i loro valori! Tuttavia, sono immutabili. Due oggetti con valore identico hanno lo stesso valore. Se vuoi un altro valore, basta crearlo - non devi dirlo a nessuno. Di per sé, i valori non vengono catturati autorevolmente; non rappresentano lo stato del sistema.

Generalmente non cataloghiamo i soli valori da soli in un database (tabella), perché la chiave / identità di tale valore sarebbero tutti i suoi attributi. (E anche perché cosa metteresti nella tabella: tutti i valori possibili?) L'utilizzo di un valore simile da un'altra tabella non farebbe che ripetere l'intera cosa nella chiave esterna.

Un'entità, d'altra parte è un'associazione (generalmente mutevole) di un'identità stabile e altri valori (e / o altre entità, ad esempio i loro valori di identità).

I valori non significano nulla da soli, mentre le entità fanno affermazioni o affermazioni di fatto sul disco, che c'è questa cosa che al momento è registrata per avere questi particolari attributi. Tali dichiarazioni vengono raccolte e acquisite e compongono nello stato del sistema.

Prendendo come esempio un punto, espandiamolo per includere un colore. Ora possiamo considerare uno di questi punti colorati come un semplice valore nello spazio di tutti i possibili punti colorati, trattati come tali che fanno di un punto colorato un valore.

Oppure, possiamo considerare un punto colorato come un'identità di punto associata a un particolare colore - come una questione di record - come una questione di stato del sistema acquisito - che viene catturato da un'autorità designata .

Un'autorità come una particolare tabella in un particolare database, o una collezione in memoria o altra struttura dati destinata a questa cattura, come una tela.

La differenza è se stiamo catturando autorevolmente tale punto colorato come una dichiarazione di registrazione, il che significa che se dico che questo punto 1,2 ha questo colore, blu, allora qualsiasi altro colore per quel particolare punto dovrebbe essere considerato falso - o- richiederebbe un cambio in stato del sistema di registrazione.

Trattata in questo modo, il punto colorato è un'entità, perché stiamo acquisendo il valore corrente dell'entità. Data un'autorità, possiamo chiedere: qual è il colore corrente di 1,2? Non possiamo farlo solo con semplici valori - non c'è autorità da chiedere!

Inoltre, un altro colore per lo stesso punto non può coesistere simultaneamente, quindi assegnare un altro colore a quell'entità richiede un aggiornamento formale (transazionale) allo stato di sistema autorevole e formalmente acquisito.

In breve, un punto colorato è solo un valore a meno che non si trovi nel contesto di un'autorità che acquisisce il colore corrente delle entità punto.

Is a point drawn on a canvas considered an entity in domain driven design?

Sì, se consideri la tela un'autorità e un sistema di registrazione che, dalla prospettiva DDD, comunica con il mondo al di fuori del contesto limitato riguardo alle identità dei punti, come la loro radice aggregata in una tela comune, o come più tele collegate ad altre radici aggregate.

Ogni punto è concettualmente un'entità sulla tela, ma ciò non significa necessariamente che ogni punto debba essere manifestato come istanza dell'oggetto: ci sono molte possibili (migliori) implementazioni.

La scelta di rendere un oggetto un tipo di entità o un tipo di valore è completamente arbitraria.

Chiaramente potresti avere un'app di disegno in cui trascini i punti e devi consentire due punti distinti con la stessa coordinata.

O un gioco "indovina chi" in cui due "persone" con le stesse proprietà sono la stessa persona.

I tipi di valore e di entità sono cose reali nel codice, ma non puoi dire da quel tipo di breve descrizione dei requisiti che sarebbe la scelta migliore per i vari verbi