Prendo spunto dal post di raffau "Come NON progettare le Entities"... e dico la mia.
Alex parlando di un classico esempio di presunta denormalizzazione dice "il motivo è semplice il cliente potrebbe cambiare indirizzo, ma se quella fattura l'avevo fatta precedentemente se la riguardo o la ristampo deve sempre riportare il vecchio indirizzo."
Raffau risponde "Che dire, alla faccia della normalizzazione."
Ma qui non si tratta di normalizazione o meno... se il caso d'uso dice che "le stampe di fatture passate devono richiedere lo stato delle cose come erano alla data della fattura..." quella che può sembrare una denormalizzazione del db in realtà NON lo è. E' semplicemente un db che salva i dati per quello che ci serve venga fatto.
Credo che dominio non deve disegnare il mondo perfetto, credo che il dominio applicativo debba aiutare a disegnare il mondo realtivo ai casi d'uso dell'applicazione... cercando di rimanere estraneo alla tecnologie che ruotano intorno all'applicazione stessa; infatti credo che tutto debba ruotare intorno al DM modellato secondo le esigenze logiche dell'applicazione (i casi d'uso). Quindi - IMHO - è il caso d'uso che ci deve aiutare a modellare entità di dominio, servizi e database... non è il database che deve dettare legge per in nome della performance assoluta. Anche in natura non tutto è perfetto in assoluto... ma ogni cosa è semplicemente perfetta per quello che è stato pensato debba fare, no?
oO0( ...tutto è relativo al caso d'uso)
posted @ sabato 9 febbraio 2008 03:35