Come creare Uuids in Entità / Aggregati DDD

2

Mentre sto imparando DDD per aiutare a costruire un'idea di app nel modo giusto;) Mi sono imbattuto in un aspetto confuso a cui sto cercando di trovare una soluzione.

Comprendo la necessità di Uuids in un'app della dimensione di cui sto creando, ma sono un po 'perso sul metodo che dovrei usare per creare Uuids per gli oggetti generati dall'utente.

Ho letto tutto sulle diverse varianti di Uuid, e ho visto i talk di Martin Fowler sul tema di Event Sourcing, quindi penso che dovrei creare Uuids che saranno uguali ogni volta che l'oggetto è stato creato.

Come posso affrontarlo anche con i dati generati dagli utenti? Il motivo è che se voglio simulare un sistema su testing per correggere un bug live, non dovrei creare lo stesso identico ID?

Sto pensando troppo a questo? Gli Uuids v4 saranno sufficienti? Ciò significherebbe che il sistema non è lo stesso su entrambi gli ambienti, o se Event Sourcing non si preoccupa veramente degli Uids?

Sono ancora abbastanza nuovo in questo, e ho provato a fondo a rispondere alle mie stesse domande con Google, ma non riesco a trovare nulla.

Grazie in anticipo.

    
posta designermonkey 17.10.2016 - 15:43
fonte

1 risposta

0

I have read all about the different variants of Uuid, and I have watched talks by Martin Fowler on the topic of Event Sourcing, so I am of the thinking I should be creating Uuids that are going to be the same every time the object is created.

UUID con nome sono ottimi per questo.

How do I even tackle this with user-generated data? The reason is that if I want to mimic a system on testing to fix a live bug, shouldn't I create the exact same IDs?

Lo stesso gioco di cui sopra - il punto di usare uuid con nome è che stai generando i tuoi identificatori in modo deterministico, il che significa che puoi riprodurli dagli stessi input.

Per la maggior parte, non ti importa mai quale sia l'identificatore è , solo che è determinato. Quindi, se i dati generati dall'utente includono un identificatore, allora va bene - durante il test del sistema, è possibile riprodurre la richiesta dell'utente con lo stesso identificatore fornito dal cliente. Questo identificatore può essere fisso o casuale, se necessario.

Se ricevi richieste utente prive di identificatore, ti consigliamo di aggiungerne una in. Puoi farlo semplicemente eseguendo l'hashing dei dati forniti dal client; ma se questo può essere duplicato, dovrai introdurre alcuni elementi aggiuntivi per assicurarti che gli identificatori siano unici.

Would you suggest that the client (written in the same language) would just use the same Uuid generating code?

Il codice deterministico è sempre molto più facile da testare di no, quindi dove ha senso, certo. Ma dal punto di vista del server, non mi interessa davvero da dove provengano gli ID generati dal client.

Also, how would you suggest using the client inputs? A sha1 of all the data for example?

Forse, ma non necessariamente. Pensa a quando vuoi che gli identificatori entrino in collisione.

Ad esempio, se sono un cliente che sta tentando di inviare un messaggio di comando, probabilmente assegnerò a quel messaggio un identificatore univoco, così che il messaggio entrerà in collisione con una copia duplicata di se stesso.

Se il messaggio è inteso per creare una nuova entità, potrebbe essere un vantaggio avere quell'identificatore collidere naturalmente con un'entità creata da un altro client. In tal caso, ci sono due casi che potresti voler gestire: i due client cercano di creare l'entità con lo stesso stato, i due client cercano di creare l'entità con stati diversi.

Se io e te proviamo entrambi a creare lo "stesso" cliente, ma uno di noi commette un errore nella scrittura dell'indirizzo, probabilmente non vogliamo due copie del cliente nel modello, ma piuttosto un cliente e forse un po 'di gestione per ottenere l'indirizzo confermato.

    
risposta data 17.10.2016 - 17:06
fonte

Leggi altre domande sui tag