Also it does not sound natural for a Customer to be less than or equal to another Customer and it does not sound natural for a Product to be less than or equal to another Product (as it stands).
Se le entità non sono ordinate nel dominio che stai provando a modellare, non c'è molto valore nella creazione di una serie di funzioni di confronto.
Più in generale, normalmente non ordiniamo le entità, tranne che imponiamo un ordine su di esse esaminando le loro proprietà interne (ordine per età, ordine alfabeticamente per cognome, ecc.), che sono in genere valori.
Eric Evans, in suo corso plurisight
I have come to believe that an entity shouldn't even have an equality comparison
Gli autori di Gridshore offrono un'analisi più lunga .
Una delle risposte che la proposta è di usare un'interfaccia rivelatrice di intenzione. Ad esempio, se ciò che realmente ti interessa nel tuo modello di dominio è se due entità condividono la stessa identità, allora dovresti fornire loro un sameIdentityAs , piuttosto che appoggiarsi allo sillabolo agnostico del dominio" uguale ".
Non credo che fornisca il valore che ci si aspetterebbe, in pratica. Stabilire "identità" di solito significa confrontare diversi valori all'interno dell'oggetto. Per le entità che hanno un concetto di identità, il valore comparato di solito è la rappresentazione del valore dell'identità.
Il che significa che esiste una funzione di mappatura (logica) che consente di accedere allo stato mutabile dell'entità, data la chiave immutabile corretta, e sameIdentityAs normalmente sarà un semplice mapping all'eguaglianza della chiave . Ciò significa che sarà inusuale dover confrontare due entità per l'uguaglianza senza avere già accesso ai tasti che avresti bisogno di fare così.
It requires code outside of Customer be responsible for determining if two customer objects are the same. Sounds a bit "anaemic" to me...
Lo fa - e ad essere onesti; più imparo sull'argomento, meno mi preoccupo dell'etichetta "anemica". Lo stato del dominio e i comportamenti del dominio dovrebbero essere separabili dietro l'astrazione con cui l'applicazione interagisce con .
Nota la distinzione: stiamo mantenendo tutto questo codice all'interno del modello di dominio; poi c'è la domanda secondaria di migliorare il design per isolare queste scelte in un modello "cliente".