L'implementazione dell'identificatore di dominio DDD dovrebbe essere ValueObject?

Naviga le tue risposte
0

In DDD abbiamo definito l'identificatore del dominio come ValueObject. Regard here

Come mai nell'ultimo progetto ho implementato tali ID in questo modo 

public struct UserID {
    public readonly string GUID;
}

public struct UserAggregateRoot {
    public readonly UserID userID;
}

Essendo un oggetto ValueObject, tuttavia nella maggior parte dei progetti che ho visto non mi baso molto su struct come questo, ma usano direttamente string. 

public struct UserAggregateRoot {
    public readonly string userID;
}

Quali sono le differenze, i benefici e i rischi nell'usarli?

    
posta b.ben 19.06.2018 - 05:31
fonte

2 risposte

4

Per quanto riguarda l'uso di ValueObjects, non vi è alcuna differenza tra la propria struttura UserID e la versione di stringa semplice. I tipi di dati primitivi (int, string, ecc.) Sono validi tanto quanto ValueObject quanto le strutture progettate per essere ValueObjects.

L'uso di una struct personalizzata ha lo svantaggio che il numero di classi / structs nel tuo progetto aumenta parecchio e devi sapere dove creare la struct dai dati primitivi che ricevi.

Anche l'uso di una struttura personalizzata presenta alcuni vantaggi:

  • Non direttamente rilevante per l'esempio del tuo identificatore, ma una struct può avere più membri, formando così un ValueObject più complesso
  • Può essere più semplice modificare la rappresentazione sottostante (ad esempio, se si desidera utilizzare una classe GUID reale invece di una stringa nell'ID utente)
  • Se diventa più difficile fare errori in ciò che viene passato ad un'altra funzione. Ad esempio, se una funzione accetta sia un ID utente sia un indirizzo, è impossibile passarli nell'ordine sbagliato se sono entrambe le strutture, ma un errore facile se entrambi sono stringhe.
risposta data 19.06.2018 - 09:28
fonte
1

What difference, benefit and dangerous using each one?

In generale, questo anti-pattern è riferito a Primitive Obsession . C'è un bel po 'di materiale buono disponibile online

C'è un carico cognitivo extra quando si ha a che fare con i primitivi; i primitivi hanno i loro invarianti, che di solito non si allineano con il tuo dominio. Ad esempio, i GUID sono lunghi 128 bit di dati, ma string può essere più lungo o più corto di quello. Concatenare insieme a string ha senso, ma non è un'operazione utile per GUID.

Che cosa significa prendere una sottostringa di un GUID?

Pubblicizzando che il sottostante nella rappresentazione della memoria dei dati è un string , offri ai tuoi consumatori l'opportunità di accoppiare il loro codice quella decisione, che aggiunge attrito se vuoi cambiarlo più tardi.

In altre parole, la decisione di utilizzare un string come rappresentazione in memoria di un identificatore è quella che può essere catturati in un modulo , riducendo il costo di cambiarlo in seguito.

Ci sono casi in cui il livello extra di riferimento indiretto è un problema; si presenta nella programmazione grafica e simili, dove la manipolazione delle strutture dati sottostanti è il punto, e la necessità di un ulteriore reindirizzamento all'interno del ciclo interno è la morte e le prestazioni. Se hai bisogno di eseguire operazioni collettive su un miliardo di identificatori, potresti voler accedere ai byte non elaborati, piuttosto che una perfetta "astrazione del dominio".

    
risposta data 19.06.2018 - 14:59
fonte

Leggi altre domande sui tag

Variabile vs valore in un'etichetta dell'interfaccia utente come parametro del metodo Procedura di caricamento best practice con entità correlate