Proprietà ID sugli oggetti Dominio in DDD

Dipende. Se la tua classe Account deve essere mappata su un database relazionale, non è solo una buona idea, ma pratica provata, utilizzare ID tecnici per ogni tabella come PK (e FK, facendo riferimento a quei PK). Secondo la mia esperienza, separare il PK tecnico di tutte le tabelle dalle "chiavi di dominio" (come il "numero di conto bancario") funziona molto bene e aiuta a evitare ogni tipo di problema tecnico. Di solito, quei PK non sono solo ID , ma <class-Name>Id , quindi nel tuo caso AccountID .

Se la tua classe sopra sarà usata come input per un generatore di codice che genererà il codice "reale" della tua lingua di implementazione e le tue dichiarazioni CREATE TABLE , alcuni codici CRUD ecc., probabilmente non lo farai è necessario aggiungere direttamente l'attributo ID nel codice classe. Se si intende utilizzare un ORM, dipende dall'ORM se può aggiungere automaticamente gli attributi ID come PK o se prevede di aggiungerli manualmente.

In un contesto DDD, potrebbe essere utile nascondere tali dettagli tecnici quando si discute il modello con gli esperti del dominio, ma mostrarli quando si modifica il punto di vista per l'implementazione del modello. Se il tuo set di strumenti consente di visualizzare il modello in questi diversi livelli di astrazione, usalo. Ma se il set di strumenti non lo consente, aggiungi gli attributi ID e comunica agli esperti del tuo dominio che si tratta solo di "attributi tecnici".

La maggior parte delle volte, il campo ID di cui si sta parlando sarebbe generato dal database, ad es. come una sequenza RDBMS o un identificatore univoco NoSQL . È quindi legato al corrispondente database utilizzato.

In base al principio Persistenza Ignoranza / Persistenza poliglotta , dovresti nascondere questo ID dal tuo dominio aggregato come il più possibile.

In pratica, il tuo dominio Aggregati potrebbe già avere un identificativo univoco. Ad esempio, un numero di serie, un codice cliente, un nome di accesso, un numero di conto, un riferimento di fattura o un codice ISBN per un libro.

Se non esiste un identificatore "naturale" nel modello, potrebbe essere un ruolo della logica di dominio generare tali identificatori autentici, ad es. seguendo un modello definito dalla normativa, o nozioni umane-friendly, seguendo la migliore prassi aziendale (è comune includere l'anno e il mese nei numeri di fattura o un identificatore alfanumerico del dipartimento responsabile del processo, ad esempio).

All'interno di Infrastructure Layer , probabilmente lascerai apparire un campo ID , specialmente se hai bisogno di costruire query SQL unite tra diverse tabelle RBDMS. Oppure, se si utilizza un ORM, non è possibile mantenere direttamente gli oggetti di aggregazione DDD come oggetti ORM, ma utilizzare un livello di traduzione "agnostico". Questo è ad esempio ciò che il nostro framework DDD propone , aggiungendo un livello di traduzione tra gli oggetti semplici DDD e gli oggetti ORM, che hanno il proprio ID ... una sorta di "ORM quadrato": sul mappatore DDD su un mappatore ORM.

DDD riguarda principalmente isolamento : non inquinare il tuo dominio con considerazione del database! Denominare un campo oggetto aggregato come ID ha un odore definitivo: probabilmente c'è un altro nome, compatibile con il Linguaggio Ubiquitous del tuo contesto limitato, che può essere usato al posto di un semplice ID .

Non penso che id sia un artefatto di database. Come sai che l'account con cui stai lavorando è corretto? Sai che è un account corretto perché probabilmente ha un identificatore univoco. Nel tuo caso l'identificatore univoco si chiama "Id", quindi naturalmente pensi che sia un artefatto di database. Per questo motivo penso che sia perfetto avere la proprietà Id nel tuo modello di dominio.

Da una nota a margine, NON avrei una proprietà di chiave esterna in un modello di dominio. Ad esempio, invece di avere AddressId nel modello di dominio, avrei una proprietà Address e questo conterrà l'id dell'indirizzo.