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

Supponiamo che stiamo modellando un modulo usando DDD; al modulo potrebbero essere associati determinati tipi di regole aziendali - forse dovrai specificare un reddito se non sei uno studente e ti verrà richiesto di elencare i tuoi figli se indichi che sei sposato. E se hai specificato un Paese, allora dovrebbe avere un Paese valido.

Questo tipo di convalida risiede nel dominio o nel livello dell'applicazione? Alcuni altri problemi che stavo prendendo in considerazione:

• Alcuni framework, come Laravel, forniscono regole di convalida che possono convalidare l'input prima che una richiesta raggiunga il controller. Si rompe DDD se la convalida viene effettuata a quel livello?

• Per casi come determinare se il paese è valido, di solito cercherò una tabella di database di tutti i paesi del mondo. Tuttavia, in DDD, questo è probabilmente (dalla mia comprensione) da fare a livello di dominio. Il livello di dominio è autorizzato ad accedere al DB o devo usare una ricerca non SQL per determinare un paese valido?

• È necessario convalidare l'input sia a livello di applicazione che a livello di dominio?

Questo tipo di convalida risiede nel dominio o nel livello dell'applicazione?

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

In genere, il messaggio ricevuto dall'applicazione avrà un aspetto di DTO. Il livello anticorruzione in genere crea tipi di valore che il dominio riconoscerà. Il comando effettivo inviato al modello di dominio verrà espresso in termini di tipi di valore convalidati.

Esempio: un comando DepositMoney dovrebbe probabilmente includere un importo e un tipo di valuta. La rappresentazione DTO esprimerebbe probabilmente l'importo come un numero intero e il codice valuta come una stringa. Il livello anticorruzione converte il DTO in un tipo di valore del deposito, che include 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 comprensibili al modello di dominio, il comando viene eseguito nel dominio, il quale può comunque rifiutare il comando in quanto violerebbe l'invariante aziendale (l'account non esiste ancora, l'account è bloccato, questo particolare account non è autorizzato a utilizzare quella valuta? ecc.).

In altre parole, la convalida aziendale verrà eseguita nel modello di dominio, dopo che il livello anti corruzione convalida gli input.

L'implementazione delle regole di convalida risiederà normalmente nel costruttore del tipo di valore o all'interno del metodo factory utilizzato per costruire il tipo di valore. Fondamentalmente, si restringe la costruzione degli oggetti in modo che siano garantiti per essere validi, isolando la logica in un posto e invocandola ai limiti del processo.

Il modello di dominio del problema include le regole aziendali del dominio. Le regole aziendali sono vincoli sugli elementi del modello. Significano 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 umani (tramite schermate, moduli, ecc.) Non è necessario che siano convalidati o assistiti. Renditi conto che è facoltativo.

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

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

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

Lo stato specifico renderebbe non valida l'entità modello? In caso affermativo, il modello deve impedire all'entità di raggiungere 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 la convalida in anticipo, 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: l'entità non è in grado di eseguire query per ulteriori dati. Ma non dovrebbe importare da dove provengono questi dati. Non importa se proviene da SQL, File o è semplicemente codificato. Ecco perché esistono i repository. Il dominio definisce il tipo di query di cui ha bisogno e consente a qualcun altro di occuparsi dell'implementazione.

Il livello di dominio deve contenere tutta la logica di convalida. Presentazione, livelli anticorruzione o altri livelli dipendenti dovrebbero riflettere questo.