Due mondi apparentemente differenti, due mondi quasi completamente distinti.
Eppure il Domain Driven, trae le sue radici proprio dal MVC, lo estende e parecchio, anche se in un certo senso lo circoscrive.
Il concetto basilare del MVC, è creare un forte disaccopiamento fra dati, la logica e chi li presenterà, questo non è del tutto perso nel D.D.D. anzi l'estensione nasce proprio nel concetto di Anti Corruption, dove un proxy di derivazione Design pattern, non fa altro che "switchare" da un "Provider" ad un Altro ma che fa le stesse cose.
Verosimilmente un cluster termine già più conosciuto.
Appaiono concetti Nuovi come l'Aggregazione o Coesione, questo perchè in D.P. un entity è solo un entity, mentre in D.D.D, un entity può essere vista come un utente, che deve accedere ad un certo numero di funzionalità ( Nb si parla di Facade... o qualcosa di non troppo distante).
Appare il concetto di Confine, un qualcosa di sottile che delimita lo spazio del dominio, conecetto che in mvc non era proprio presente... e forse non era nemmeno necessario. Però per soluzioni in D.D.D. è necessario imporre o impostare un limite.
Per questo concetto però potrebbe essere necessario almeno un esmpio.
In Mvc la soluzione può essere costituita da più progetti come un sito web e varie dll, o una windows application e varie dll, in D.D.D una soluzione può essere l'insieme di applicazioni presenti in un azienda che hanno come punto d'ingresso l'utente di LDAP...
Ora non è difficile comprendere perchè serve un confine...
A tale proposto si parla di Domain Layer ( simile business Logic ) ma è il punto in cui il software vive.
Si parla di immutabilità, oggetti che possono essere osservati che possono avere iterazione con altri oggetti, ma che non cambiano il loro stato.
Tuttavia si parla di Ubiquty Languages ... già perchè in programmazione ( da sempre ) si cerca di dare a tutti una regola nella definizione delle "cose". In D.D.D il concetto è forte e persistente dato che la vastità di una soluzione può essere considerevole...
E' di estrema importanza che tutti si parli "nella stessa lingua e degli stessi argomenti chiamandoli sempre con il loro nome". E va da se che anche nella stesura del codice si debba sempre mantenere chiaro il contesto.
E i test su architetture simili ??
Già in D.D.D si parla tanto anche di Test Driven, una metodologia che consente di scrivere codice
in base anche ai test che dovranno essere fattti.
Certo Mvc è "fondatore" della buona programmazione "D.D.D." estente quanto di meglio c'era e in parte lo migliora
Nessun commento:
Posta un commento