Entity and Value Object non fanno parte del linguaggio Ubiqtious. Questo dovrebbe impedirmi di usarli?

Se ti sto capendo bene, ogni classe del tuo dominio si basa su due classi.

1. Entità che impone un campo ID di un singolo tipo, strettamente accoppiato al tuo database e vari override di uguaglianza e riflessione delle classi

2. Valore che emula un tipo di valore e tenta di imporre immutabilmente

Sto facendo fatica a capire le motivazioni per questa idea.

Il suggerimento Entity sembra essere un ritorno al pattern Active record, con il suo stretto accoppiamento a Nhibernate, presupposto che la tua chiave primaria possa essere un int lungo per tutti gli oggetti e che un valore di 0 significhi che l'oggetto non è 'reale' perché il database deve generare id.

L'oggetto Value sembra un tentativo maldestro di sostituire struct. Sei preoccupato per > Le strutture 16byte sono lente e le sostituiscono con la riflessione?

Entrambi eseguono l'override degli operatori, cosa che è raramente consigliabile.

Ci sono alcuni casi limite in cui ti lamenterai che il tuo oggetto business è una classe di riferimento e vuoi creare un costruttore di copia.

Ci sono alcuni rari casi limite in cui si desidera confrontare gli oggetti e semplicemente confrontare l'Id non è sufficiente.

Ma questi non sono il tipo di enormi "trucchi" imprevisti che richiedono di pianificare l'intera struttura del codice in anticipo in caso si presentino.

La distinzione tra valore e tipi di riferimento non dovrebbe essere qualcosa che emerge in una discussione con un analista aziendale.

Aggiornamento: riepilogo dei commenti

Quando si confrontano gli oggetti del dominio nella propria applicazione, la mia raccomandazione è di confrontare i campi Id, ad es.

var cust1 = repo.GetCustomerByName(name);
var cust2 = repo.GetCustomerByLastName(lastname);

var areCustomersTheSame = cust1.Id == cust2.Id

piuttosto che confrontare direttamente gli oggetti. vale a dire.

var cust1 = repo.GetCustomerByName(name);
var cust2 = repo.GetCustomerByLastName(lastname);

var areCustomersTheSame = cust1 == cust2

Il secondo metodo richiede la sovrascrittura degli operatori predefiniti, che è più lavoro e non è previsto. Inoltre significa che non puoi fare il confronto di default per vedere se il riferimento è lo stesso.

C'è una terza complicazione in cui gli Id possono corrispondere ma alcuni altri campi sull'oggetto sono cambiati, o non hai affatto alcun campo di identificazione. Qui vorrei incapsulare quella logica in un'altra classe.

CustomerComparer.IsAllFieldsMatch(cust1,cust2)

La mia sensazione generale è che se devi controllare se gli oggetti sono sempre gli stessi nella tua Business Logic. Stai facendo qualcosa di sbagliato da qualche parte. Ottieni oggetti una volta, fai le tue cose e disponili.

Entity and Value Object are not part of the Ubiqtious language. Should this stop me from using them?

Non dovresti utilizzare termini del dominio di implementazione per cercare di spiegare cosa sta succedendo nel dominio aziendale.

Entity e Value Object sono nomi per schemi di implementazione, in modo simile a Iterator , Command , Domain Model ....

Un altro modo di pensare a Entity e ValueObjects è che descrivono ruoli che le implementazioni possono riprodurre. Ad esempio, se CustomerProfile è un Entity , allora ciò potrebbe significare che implementa un metodo identity() che restituisce un identificatore che è un Value Object , che a sua volta promette che l'identificatore è immutabile e adatto all'uso come chiave in una struttura dati. Quindi puoi creare un generico Repository che può agire come una raccolta in memoria di un oggetto che implementa il ruolo Entity fornendo un identificatore che supporta il ruolo Value Object

interface Entity<Id implements ValueObject> {...}

interface CustomerProfile {...}

HibernateCustomerProfile implements CustomerProfile, Entity<HibernateCustomerId> {...}

class HibernateCustomerProfileRepository extends Repository<CustomerProfile> {...}

Ma queste convenienze sono quasi sempre scese nell'impianto idraulico, non fanno parte dell'implementazione dei comportamenti del dominio.

Is it suitable to use ValueObject and Entity bases classes in a real implementation or is it just a thought exercise? Do you use them?

Non li uso come classi base; Di solito lavoro in lingue in cui sono limitato a una singola classe base per ogni implementazione, e il valore di una classe base comune non compensa i costi.

Come interfacce, sono solo metadati. Non hanno uno stato proprio.

In un linguaggio di implementazione con mixin, potrebbero essere utili. Sono scettico, ma non ho abbastanza esperienza con loro per pubblicizzare un parere informato.