In DDD, la logica dell'applicazione di convalida o la logica del dominio?

Does this kind of validation lives in the domain or application layer?

Application. Il termine di ricerca magico che desideri è anti livello di corruzione

In genere, il messaggio ricevuto dalla tua applicazione sarà un po 'di sapore di DTO. Il tuo livello anti corruzione tipicamente creerà tipi di valore che il dominio riconoscerà. Il comando effettivo inviato al modello di dominio sarà espresso in termini di tipi di valore convalidati.

Esempio: un comando di DepositMoney includerebbe probabilmente un importo e un tipo di valuta. La rappresentazione DTO probabilmente esprimerebbe l'importo come un numero intero e il codice valuta come una stringa. Il livello anti corruzione convertirà il DTO in un tipo di valore Deposita, che includerebbe un importo convalidato (che deve essere non negativo) e un CurrencyCode convalidato (che deve essere uno dei codici supportati nel dominio).

Dopo aver analizzato correttamente il comando in tipi che il modello di dominio comprende, il comando viene eseguito nel dominio, che può ancora rifiutare il comando sulla base del fatto che violerebbe l'invarianza di business (l'account non esiste ancora, l'account è bloccato, questo account particolare non è autorizzato a usare quella valuta? ecc.).

In altre parole, la convalida aziendale sta per accadere nel modello di dominio, dopo che il livello anti corruzione convalida gli input.

L'implementazione delle regole di convalida sarà normalmente disponibile nel costruttore del tipo di valore o nel metodo factory utilizzato per costruire il tipo di valore. Fondamentalmente, si limita la costruzione degli oggetti in modo che siano garantiti come validi, isolando la logica in un punto e invocandola ai limiti del processo.

Il tuo modello di dominio problematico include le regole di business del tuo dominio. Le regole aziendali sono vincoli sugli elementi del modello. Significa che un ascensore non si muove con la porta aperta, che le merci deperibili non vengono caricate in un contenitore non refrigerato e che un ordine annullato non viene spedito.

Ciò non significa che quando il tuo dominio interagisce con gli esseri umani (tramite schermi, moduli, ecc.) non è necessaria alcuna convalida o assistenza. Ti rendi conto che è facoltativo.

Considera che esistono due tipi di regole aziendali: - regole di proprietà che vincolano gli attributi di un oggetto e regole di collaborazione che vincolano l'aggiunta e la rimozione di collaborazioni tra oggetti.

Le regole aziendali sono diverse dalle regole logiche, che sono correlate al tuo linguaggio di programmazione e controllano che i valori siano stati forniti e non siano nulli ecc.

Nota: non esiste alcun concetto nel DDD di "modellazione" del tuo modulo.

Lo stato specifico renderebbe invalida l'entità modello? Se sì, allora il modello deve impedire all'entità di arrivare a quello stato. Ciò significa che il modello deve sapere come convalidare se stesso.

Ma c'è un piccolo problema: la validazione del modello spesso avviene troppo tardi. Spesso, vogliamo fare presto la convalida, quindi l'utente non deve aspettare troppo a lungo. Ecco perché la convalida viene spesso inserita nella logica dell'applicazione.

Per quanto riguarda il contesto di convalida: non vi è alcun problema di entità in grado di interrogare per dati aggiuntivi. Ma non dovrebbe importare da dove vengono questi dati. Non importa se proviene da SQL, File o è solo hard-coded. Ecco perché esistono repository. Il dominio definisce il tipo di query di cui ha bisogno e consente a qualcun altro di occuparsi dell'implementazione.