In un DDD per lo sviluppo del dominio guidato, avere una convalida su un DTO che chiama un servizio esterno è sbagliato, se sì, dove dovrebbe essere?

Question

In un DDD per lo sviluppo del dominio guidato, avere una convalida su un DTO che chiama un servizio esterno è sbagliato, se sì, dove dovrebbe essere?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (1 voti)

-1

Ho questa domanda, è più sul modello e in teoria ciò che è sbagliato o meno invece che se è possibile o meno (perché lo è).

In un design DDD, ho un DTO che sto convalidando, per controllare non valori null e altri valori certi.

C'è un campo che ho appena realizzato deve essere convalidato attraverso un servizio che farà una richiesta di rete.

Sto usando guice e questo DTO è fuori dal contesto (significa che non posso iniettare servizi) ma penso che dovrei essere in grado di farlo.

Secondo la teoria, il DTO dovrebbe avere questo tipo di convalide? questo è e non è la validazione dell'input nello stesso punto, questo perché voglio essere sicuro sia valido, ma valido dal punto di vista del business (secondo me), ma penso anche che non faccia affidamento sul livello anti corruzione.

Il flusso è così:

Viene chiamato il controller che riceve come parametri DTO con il proprio validazioni, le DTO non sono nel contesto guice e non possono essere iniettate un servizio o altro
Il servizio è chiamato (qui ottengo informazioni come utente registrato, servizio può inject) Service esegue alcune elaborazioni all'interno e quindi chiama una facciata (la facciata può iniettare)
Chiamate di facciata ai repository, questo metodo è transazionale e quindi salva le informazioni.

Il mio validatore è fuori dal contesto e non può iniettare nulla.

Qualche idea dove sarebbe il migliore? Questo è un flusso di un endpoint che salva informazioni, questo è il motivo delle chiamate.

Ho visto i validatori sul repository, esso chiama un livello anti corruzione, ma per me è troppo tardi per convalidare questo tipo di informazioni (la convalida delle informazioni esiste attraverso una API esterna).

Le convalide nel DTO sono fatte nel costruttore. Altri livelli hanno ulteriori validazioni (come non null, ecc.)

domain-driven-design validation

posta jpganz18 10.10.2018 - 16:59

fonte

4 risposte

Leggi altre domande sui tag domain-driven-design validation

FSM sarà una buona soluzione? È ragionevole usare Javascript MVC Frameworks per applicazioni web a pagamento closed source? [chiuso]

score 2 · Answer 1

According the theory, should the DTO have this kind of validations?

Normalmente no.

Ciò che il DTO potrebbe includere è un timestamp: a che ora erano note le informazioni contenute nel DTO?

L'argomento è simile a questo: se è necessario verificare con il servizio remoto per sapere se qualcosa è valido, allora la verità potrebbe cambiare mentre il messaggio è in volo - o mentre la risposta di convalida sta tornando da il servizio remoto o mentre il DTO è in transito verso la sua destinazione.

Le informazioni sono obsolete non appena vengono scritte.

Invece, acquisisci esplicitamente le informazioni su quando i dati erano conosciuti come validi e passali oltre senza effettuare la chiamata al servizio remoto.

In altre parole: se hai davvero bisogno di garantire che i tuoi dati locali siano in accordo con alcuni dati remoti, allora fallo in modo asincrono al vero lavoro.

(E inoltre, sii diffidente nei confronti del tuo progetto - perché questi due pezzi di dati devono essere archiviati in posti diversi?)

score 1 · Answer 2

No, il DTO dovrebbe normalmente contenere solo dati strutturati e convalida di base riguardanti la sua struttura interna, come non null, lunghezze di stringa, intervalli numerici, ecc.

Se è necessario convalidare esternamente, è necessario utilizzare una fabbrica. Uno schema comune è quello di utilizzare un ACL che si traduce da modelli remoti ( cioè Entità) a modelli locali (es. oggetti valore). L'ACL non consentirebbe la creazione di un DTO non valido (non consentito dalle regole aziendali).

A seconda della tua architettura / tecnologia / linguaggio di programmazione, il DTO viene creato in modo asincrono, da un processo diverso in background o sincrono, prima che venga utilizzato.

score 1 · Answer 3

Alcuni pensieri:

La questione se sia o meno valido convalidare un DTO è in gran parte irrilevante dal punto di vista del DDD.

Devi ricordare che l'obiettivo del DDD è affrontare problemi di dominio complessi. È prevalentemente agnostico per i dettagli tecnici di strati / classi infrastrutturali.
Un Controller che chiama un Service che chiama un Facade che chiama un Repository , in una transazione, tutto ciò per convalidare un DTO ... Questo è un odore di codice proprio qui se me lo chiedi. I repository vengono normalmente chiamati solo in situazioni specifiche in cui raramente è necessario passare attraverso così tanti cerchi.

Mi sembra che tu stia irriconoscendo le regole di business nella tua base di codice quando dovrebbero essere nel livello Domain, o forse DDD non è la lente giusta per esaminare il tuo problema.

score 1 · Answer 4

Penso che il problema qui sia che stai incorniciando i tuoi dati in modo errato. Il tuo DTO non può contenere regole di convalida che richiedono dati remoti da eseguire (cosa significa DTO di nuovo?). In caso contrario, un DTO dovrebbe avere solo le regole più semplici per quanto riguarda i dati in suo possesso. Il tuo dominio è responsabile per la convalida aziendale. Idealmente, il processo segue un flusso simile a (dal punto di vista del livello dell'applicazione):

Recupera tutti i dati (oggetti dominio) necessari per eseguire il comando richiesto
Coordinare i dati (dire ai dati di mutare se stessi)
Persistere dati mutati

È importante sottolineare che la convalida avviene durante il passaggio 2 all'interno del modello di dominio. L'applicazione richiama semplicemente chiamate / organizza i parametri nel tuo dominio. La tua domanda sembra essere la combinazione di passaggio 1 e passaggio 2.

C'è un motivo per cui non è possibile recuperare i dati necessari per convalidare questo campo extra? Non vi è alcun vincolo sul DDD che impone che ogni oggetto dominio debba provenire da una singola origine dati. Senza le tue esigenze specifiche è difficile offrire una soluzione appuntita, ma ti suggerisco di provare a modellare la tua gestione dei comandi come sopra. Cioè, invece di usare un servizio per validare alcuni campi scalari, usa un servizio (o repository) per recuperare un oggetto dominio (entità / aggregato / valore) che incapsula i tuoi dati. Questo può essere passato come parte del coordinamento nel passaggio 2 (pensa ai vettori di cambiamento per questo pezzo di dati. Non ci sono regole?).

Ha senso?