DDD - Come devono essere trattate le entità di ricerca?

Question

Stiamo lavorando a un progetto usando DDD, ma stiamo bloccato su come trattare le entità di ricerca. Ad esempio, abbiamo un aggregato chiamato "Cliente" e l'entità "Cliente" è anche la radice aggregata. L'entità "Cliente" ha la proprietà "CustomerTypeid".

Ma abbiamo anche un'entità "CustomerType" che risponde a tutti i tipi di clienti esistenti (ID e descrizione). Ci sarà una funzione di amministrazione che consente agli utenti di mantenere i tipi di clienti (cioè l'aggiunta di un nuovo tipo di cliente, ecc.).

Si prega di notare che non sto parlando di modificare il tipo di cliente per un cliente specifico, ma di manutenzione dell'elenco dei tipi di clienti.

Mi scuso per la storia di lunga durata, ma ecco le mie domande:

• Ho ragione pensando che "CustomerType" sia un'entità e non un oggetto di valore?

• "CustomerType" dovrebbe essere all'interno del "cliente" aggregato o dovrebbe essere all'interno del proprio aggregato in quanto lo accederemo e lo manterremo al di fuori del contesto di un cliente specifico?

• Se questa entità e qualsiasi altra entità che sono entità di ricerca di base (come lo stato del cliente, il tipo di prodotto, ecc.) Dovrebbero essere aggregati da soli (ed essere le radici aggregate di questi aggregati) non finirò con centinaia di repository ? (poiché ogni radice aggregata avrà il proprio repository)

Come puoi vedere, sto entrando in una confusione qui e devo solo essere puntato nella giusta direzione.

==================================== Ho provato a scrivere un codice in risposta alla risposta di Eulerfx ma non potrei " Fallo funzionare, quindi lo metterò qui.

Per quanto riguarda il punto 2, sullo schermo mostreremo ovviamente solo la descrizione del tipo (ad esempio "personale"). Significherebbe che finirei con qualcosa di simile?:

Public Class Customer
    Inherits EntityBase(Of Integer)
    Implements IAggregateRoot

    Public Property CustomerID As Integer
    ...
    Public Property CustomerType As CustomerType
    ...

e

La classe pubblica CustomerType eredita Entitybase (di Integer) implementa iaggregateroot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

O la proprietà all'interno del "cliente" di classe dovrebbe essere CustomerTypeid?

Per quanto riguarda il punto 3, qual è la differenza tra un contesto aggregato e limitato? L'aggregato "cliente" (con "cliente" non sarebbe la radice aggregata), che contiene anche entità e valutare oggetti che esistono solo nel contesto del cliente, non essere un contesto limitato?

Answer 1

1. Sì, da allora CustomerType ha un'identità e una descrizione associata è un'entità.

2. Se il Customer la classe ha a CustomerType proprietà o a CustomerTypeId La proprietà dipende dal fatto che debba accedere ad altre proprietà su CustomerType. In entrambi i casi, CustomerType è la propria entità che ha il proprio repository.

3. Se hai centinaia di entità, in particolare del tipo specificato, potrebbe essere un'indicazione che il progetto sta diventando troppo grande e potrebbe essere necessario partire in contesti limitati appropriati.