Ho trovato molta difficoltà nel capire come e quando è necessario implementare per una Entity un ID univoco. Come prima cosa ho scoperto che Eric Evans distingue le entity proprio dal fatto che posseggono un Identity, composta da uno o piu' attributi, altrimenti sarebbero dei semplici Value Object.
Una prima cosiderazione è: se lo scopo di una Identity è quello di classificare il mio Object come unico, allora due Object dello stesso tipo con la stessa Identity, sono due copie dello stesso oggetto.
Una prima metodologia, semplice e intuitiva, è quella di creare una Identity nel nostro Db. Ma in questo modo, come segnala anche Mauro, restiamo troppo legati alla struttura del DB, e quindi non siamo astratti per nulla.
Una seconda tecnica che ho trovato molto interessante, la propone proprio Mauro su questo post in GUISA: Key.
[OT] Devo dire che la maggior parte delle soluzioni che trovo sul DDD (Domain Driven Design) me le fornisce sempre Mauro che è diventato il mio Pusher C# di fiducia!![/OT]
Le considerazioni a riguardo sono molte, ma se vogliamo seguire il Modello DDD, la regola è : Se il nostro oggetto deve essere unico per tutto il ciclo di vita del software, allora questo sarà una Entity con una Identity, al contrario, se il nostro oggetto dovrà essere condiviso e dovrà cambiare valore, allora sarà un Value Object e non necessità di una Identity.
A voi le considerazioni.