DDD e MongoDB: Va bene lasciare che Mongo crei ObjectIDs?

Question

In base a DDD (Blue book, Evans) una Factory ha la responsabilità di creare una radice di aggregazione in uno stato valido. Significa che dovrebbe essere in grado di creare l'id tecnico (objectId nel mondo mongoDB) e l'id del dominio?

Da un lato, questo sembra un dettaglio tecnico e sembrerebbe giusto lasciare che Mongo gestisca la creazione dell'ID.

D'altra parte, l'esecuzione di query che consente da id (avendo getById in un repository DDD) espone l'id tecnica al dominio, che a sua volta renderebbe la responsabilità della fabbrica per crearlo.

Forse non riesco a capire i diversi casi d'uso/sovrapposizione, ecc. Di Id tecnico vs DomainId o forse sono troppo zelante, ma apprezzerei comunque la tua opinione.

In breve: In DDD: una factory può essere in grado di creare l'ID tecnico e l'ID dominio?

possibile implementazione: Hi/Lo (How to set the hilo sequence starting value in MongoDB Norm?)

EDIT: anche se il/lo modo hi espone la fabbrica allo strato di persistenza, che è qualcosa che solo il repository dovrebbe sapere. hmmm

Grazie

Answer 1

Le fabbriche non c'è bisogno di preoccuparsi con l'ID in quanto la validità di un aggregato è ortogonale alla identità. L'identità può essere assegnata in diversi modi, sia come ID incrementale da un database relazionale, nel qual caso il repository deve gestirlo, sia come UUID/GUID nel qual caso può essere assegnato dalla fabbrica, o repository, o anche il client chiamante che è conveniente perché poi il client ha la chiave di default.

Quando possibile, cerco di mantenere un'unica identità per gli aggregati. Non sono sicuro che MongoDB richieda un ID tecnico aggiuntivo, ma se lo fa e l'ID del dominio non può essere usato al suo posto, MongoDB dovrebbe gestirlo da solo e dietro le quinte.