La validazione, a livello di dominio, di business e di DAL, è la vera garanzia che le entità che stiamo creando/utilizzando contengano dati coerenti.
Nella versione finale dell’applicazione è ovviamente assolutamente cruciale che esista un unico punto centralizzato dell’applicazione (ovunque esso sia) che si occupi della validazione di dominio ed un altro che si occupi della validazione a livello di database, in modo da sapere sempre dove andare ad agire quando effettuiamo del refactoring sul domain model (discorso differente per la validazione a livello di casi d’uso, che si può centralizzare ma rimane comunque frammentata).
La cosa di cui però mi sto sempre più rendendo conto “grazie” (…) ai ritmi MOLTO estremi con cui mi ritrovo costretto a sviluppare in queste settimane è il grande beneficio che porta, in caso di modifiche di requisiti in corsa o comunque post-deploy, il fatto di modificare, ovviamente dopo il Domain Model :-), prima di tutto il codice di validazione e poi le altre parti dell’applicazione.
Una sorta di RED-GREEN refactor applicato alla validazione.