Questa mia convinzione è valida in molte situazioni ed per molti progetti, dove spesso nel team esiste la convinzione che: le tecnologie usate in un software debbano per forza essere omogenee ed utilizzate dappertutto. Un palese esempio di questa sindrome si ha quando le obiezioni all’uso di Nhibernate o Entity Framework sono: “cosa succede poi se una query non riusciamo a farla in LINQ o con HQL?”, oppure “non conviene perché poi sappiamo che per i report o per le operazioni massive un ORM non è adatto”.
Il problema alla base di queste obiezioni è principalmente questo: se si decide di usare un ORM, non significa che questo debba diventare l’unico modo di accedere al database. Sebbene sia chiaro che è preferibile limitare il numero di scelte tecnologiche adottate nei nostri progetti, per evitare codice immanutenibile, è possibile che si utilizzi un ORM per tutte le parti di business logic, ma per i report e per le operazioni massive si potrà utilizzare il un buon vecchio dataset e delle stored procedures. In questo caso sto limitando a due possibili scelte (ORM o Dataset) con delle chiare regole che mi fanno capire quando è meglio usare uno o usare l’altro.
In sostanza vorrei evitare l’antipattern: Usiamo lo stesso pattern ovunque
Immagine: © Alberto Brandolini 
Questo è ancora più vero quando si parla di architetture nuove/complesse/strane/di_cui_non_si_ha_esperienza, come CQRS. La sindrome più ovvia è: non conosco bene CQRS ed Event Sourcing, però so che in alcuni punti del mio software queste tecnologie potrebbero portare grandissimi vantaggi, per cui inizio ad applicarlo nelle parti facili di progetto, cosi quando arrivo a quelle difficili, dove CQRS/ES mi da vantaggio ho già un po’ di confidenza.
Questo spesso porta più danni che benefici, perché state utilizzando:
- una architettura di cui non siete padroni
- in una parte in cui non è necessaria
La conclusione è: spendete un sacco di tempo e perdete produttività perché ad esempio state lavorando su una parte decisamente CRUD, con poche logiche di dominio, ma usando un Event Store e separazione tra logica e lettura. Il risultato? Più dolori che vantaggi, perché state adottando un pattern complesso per risolvere un problema semplice.
Andando ad informarsi in rete, ad esempio con i post di Greg o Udi, emerge che probabilmente solo il 20% dei progetti beneficia realmente di CQRS; in questo caso io ho una chiave di lettura leggermente differente: CQRS va probabilmente usato solamente nel 10%/20% del proprio progetto, difficilmente potremmo applicarlo ovunque. In questo caso bisogna vincere la resistenza data dalla falsa convinzione che un pattern va adottato ovunque, ma sposare la realtà e capire che nelle proprie applicazioni, aree differenti potranno convivere con pattern differenti. In DDD è poi chiave il concetto di BOUNDED CONTEXT, per cui, dato che ogni BOUNDED CONTEXT comunica all’esterno con messaggi senza esporre logiche interne, è chiaramente possibile limitare l’uso di un pattern in un determinato BOUNDED CONTEXT.
In questo scenario è fondamentale l’individuazione dei BOUNDED CONTEXT, perché se si sbaglia a tracciare la linea tra contesti il conto potrebbe essere salato, però questo indipendentemente dai pattern utilizzati.
Gian Maria.