“DDD”…un acronimo, mille dubbi.
Se da una parte noto un sempre crescente interesse rispetto a questa “metodologia”, dall’altra mi accorgo che iniziano ad insinuarsi vari/parecchi dubbi sulla sua effettiva validità/efficacia tra le persone con cui mi confronto ultimamente.
Se ne parla tanto, da tempo, ma di esempi veri e propri ce ne sono sempre pochi, rischiando di confinarne i principi e le linee guida ai confini della leggenda: ma si può veramente fare? è sostenibile? ma come si fa?
Ultimamente, inizio addirittura a percepire i primi spifferi relativi ad una scarsa valenza del DDD nella fase implementativa di un progetto: “tante belle idee, ma stringi, stringi…”
Il problema non è il DDD, ma l’uso che se ne fa. Se poi ci mettiamo che i pochi (troppo) semplici esempi che abbiamo sotto gli occhi cercando in rete, molto spesso (IMHO) sono molto lontani dalla direzione in cui DDD/CQRS/ES ci spingono…chiudiamo il cerchio. Molti (mi metto anch’io nel coro) credono di fare DDD, ma tante volte sono ben lontani da una sua, anche minima, parvenza. Presi dall’entusiasmo, cerchiamo di infilare aggregate, repository, bounded context (and so on) in qualsiasi progetto, quando, in fin dei conti, non ne avremmo bisogno, dimenticandoci “bellamente” del sottotitolo del libro da cui tutto ha preso origine: “Tackling complexity in the heart of software”.
Se non c’è complessità, perché introdurre tutto il cerimoniale che il DDD mi impone/propone? Ma quando la complessità c’è, è evidente o è percepibile, vi posso assicurare che i principi e le linee guida sviscerabili dal libro, con qualche aggiunta qua e là, hanno un valore aggiunto inestimabile, quel valore aggiunto che, con il crescere del progetto, ci permette di gestire veramente a basso sforzo la complessità.
Non ho risposte certe, non ci sono medaglie in palio :-), ma se volete vedere e condividere la nostra visione e soprattutto una possibile implementazione vi aspetto al primo evento di Guisa che si terrà a Treviglio il 4 maggio.
Mi raccomando non mancate.
