Configurazione del comportamento dell'entità DDD

3

In uno dei prodotti con cui lavoro abbiamo una radice di aggregazione con un sacco di logica di dominio, e ora ho il requisito di rendere configurabile un piccolo elemento di comportamento.

Per fare un esempio, diciamo che ho un'entità e questa entità ha molte programmazioni, questi orari mi dicono se sono in orario o no e hanno modi diversi di farlo secondo il loro tipo (polimorfismo), uno di questi queste specifiche devono tenere conto di un parametro configurabile del database che mi dà il risultato.

Ora, tutte le possibilità che ho pensato non sembrano esatte

  1. Non ha senso rimuovere la logica di dominio dal dominio solo a causa di questo requisito.

  2. Inoltre, non è possibile che Entity acceda a un repository, almeno non considerato corretto da DDD

Ho pensato a molti altri modi per risolverlo, ma finisco sempre per dover istanziare manualmente il repository all'interno dell'entità o avere il mio livello applicazione per iniettare questi valori di configurazione per proprietà che interrompe il progetto poiché non c'è modo di forzare il valore da iniettare prima che un metodo possa usarlo per essere chiamato.

Quali alternative ho qui?

    
posta bateloche 07.02.2017 - 23:40
fonte

1 risposta

2

Ricorda che un repository ti dà accesso a una radice aggregata. Se stai tentando di accedere a un altro repository da un'entità, stai sostanzialmente cercando di uscire dall'aggregazione. Questo è in genere un'indicazione che la tua entità non è realmente un'entità di dominio, o almeno questo aspetto di ciò che stai cercando di fare non lo è. È una responsabilità che forse deve essere delegata.

Forse la determinazione delle pianificazioni è meglio in alcuni servizi di pianificazione come servizio di dominio (che vive nello stesso aggregato) o nel tuo livello di applicazione.

Se lo schedulatore è un concetto di dominio. Il valore di configurazione può essere ottenuto semplicemente tramite un servizio astratto (implementato con un oggetto query) all'interno dello stesso aggregato. Non deve necessariamente essere un repository (stai solo leggendo un valore, non c'è nessuna semantica della raccolta qui).

Se la cosa che stai cercando di fare è davvero scomoda da fare attraverso un servizio di scheduling allora puoi accedervi usando il doppio invio sulla tua entità (accettalo come parametro come hai detto).

    
risposta data 08.02.2017 - 02:45
fonte