[TYPO3-UG Italy] Fwd: TYPO3 CMS 6.1 - Le novità

Tonix (Antonio Nati) tonix at interazioni.it
Wed May 8 10:04:43 CEST 2013


Il 08/05/2013 08:57, Ivano Luberti ha scritto:
> ......

> Invece sulla DDD chiederei a Tonix, per capire la sua affermazione non 
> per criticarla, di citare a quale definizione di DDD si rifaccia per 
> dire che questo approccio non si occupa di programmazione.
> L'ambizione di costruire framework per sviluppare software con 
> approccio DDD mi sembra molto diffusa e non un'idea balzana di un 
> gruppetto di sviluppatori.
> Poi il nome dice chiaramente che nasce come approccio alla 
> progettazione (design) e non allo sviluppo, pero' questo non significa 
> che non possa essere esteso.
>

Come tu dici, la definizione di DDD è auto-esplicativa.
Se prendi un libro come "Domain-Driven" Design di Eric Evans, la 
spiegazione è molto più dettagliata e comprensibile.

DDD si preoccupa che i documenti scambiati col cliente (inteso come 
fruitore finale), le specifiche funzionali, le specifiche di collaudo, 
l'analisi logica e quant'altro attinente, siano scritti esattamente nel 
linguaggio del cliente, e seguano la sua logica. Il cliente non deve 
imparare il linguaggio informatico, è l'informatico che deve adeguarsi 
alla logica del cliente. Va risolto il problema del cliente, non 
dell'informatico.

I documenti scambiati col cliente servono solo per concordare gli 
obiettivi e cosa consegnare, senza ambiguità. Lo sviluppo poi seguirà in 
genere altre strade.

Chiaramente, per questo motivo, la gestione è costosa e si parla di 
progetti consistenti: diciamo da almeno sei mesi di lavoro in su, dove 
per l'analisi si spendono almeno uno-due mesi (non è sempre così, ma 
tanto per dare un valore concreto e capirci).

In questi casi è praticamente impossibile mappare uno ad uno le esigenze 
applicative con una funzione specializzata. E' molto più probabile che 
ci siano più strati di chiamate (o librerie o classi), specializzati in 
singole parti, che poi vengono chiamati dallo strato più alto per 
comporre quanto necessario: chiamate specializzate al DB, chiamate 
specializzate per l'output, chiamate specializzate di controllo, 
chiamate base di gestione del DB (per ogni tabella o per ogni tipo di 
record se è il caso), chiamate per ulteriori funzioni aggregate.
Quella che può essere una funzione mappata esattamente sopra una 
necessità del cliente è facile che sia una macro-chiamata che al suo 
interno usi altre decine di chiamate interne specializzate. E per ideare 
queste decine di chiamate in genere si usa una tecnica di analisi, 
scomposizione, modularizzazione, prototipazione, collaudo che ovviamente 
prende spunto dai documenti scambiati col cliente, ma che ha poca o 
nessuna attinenza con le funzioni finali necessarie. In genere parte 
tutto dallo studio accurato del DB (dove il DB potrebbe avere un disegno 
interno completamente diverso dalla vista presentata al cliente) e dalle 
funzioni di gestione dello stesso.

Non va fatta confusione con quello che è un prototipo, dove disegni 
esattamente quello che vuole il cliente e simuli le sue richieste con 
chiamate mappate uno ad uno, perché in genere:

  * in un progetto complesso, svolgono solo una funzione visiva di
    conferma delle specifiche, che poi andranno tradotte in modelli più
    complessi e strutturati di sviluppo;
  * in un progetto minimale possono diventare il programma da
    consegnare, ma parliamo di una situazione limite che ha poca (se non
    nulla) analisi e poco valore aggiunto.

Questo di cui ti parlo l'ho sperimentato sulla mia pelle in parecchi 
progetti dai 5 ai 25 anni/uomo (a tempo pieno, ovviamente), in COBOL (!) 
/ Pascal / C / C++, e, scalato per ovvi motivi, lo sto applicando anche 
nei progetti che sto sviluppando ora in PHP con TYPO3 (diciamo con 
dimensioni da almeno 1 anno uomo) o in VB o Java per l'interazione da 
desktop con i siti TYPO3.

Per questo ti dico che queste tecniche usate da TYPO3 nelle ultime 
versioni sono utili per one-man band, che lavorano in piccoli progetti, 
ma non sono applicabili in progetti aziendali consistenti.

Per TYPO3 è corretto parlare di MVC, non di DDD.

Ciao,

Tonino

-- 
------------------------------------------------------------
         Inter at zioni            Interazioni di Antonio Nati
    http://www.interazioni.it      tonix at interazioni.it
------------------------------------------------------------



More information about the TYPO3-UG-Italy mailing list