Perché DDD fa così fatica a prendere piede?

Perché ogni volta che parli con qualcuno di DDD, o CQRS o EventSourcing, il discorso cade sempre sul "...e ma è costoso..."?

IMHO

Siamo ottusi, manager in cima alla lista (fate il vostro, facciamo il nostro, mea culpa).

Da tecnici quali siamo la mostra mente è inevitabilmente deviata e pensiamo immediatamente alle implicazioni tecnico/tecnologiche che le scelte progettuali/architetturali portano con se.

Peccato che come al solito abbiamo letto il manuale delle istruzioni a pezzi, saltando qua e là, comprendendo poco o nulla della visione d'insieme.

Visione d'insieme

Quello che ci siamo persi per strada è uno dei concetti fondamentali di DDD, che, avendo purtroppo poco da spartire, almeno a prima vista, con problemi tecnici, viene bellamente ignorato: context mapping.

Il context mapping, e i deliverable prodotti, i bounded context, sono forse la cosa più importante che DDD porta con se, ci servono per iniziare a comprendere e modellare il modello mentale dell'utente e di conseguenza il Domain Model stesso.

Il context mapping ci fornisce quella conoscenza e presa di coscienza del dominio tale da rendere semplicemente un non problema le eventuali complessità tecniche derivanti dall'introduzione di DDD, eventuali.

Dato il contesto diventa anche estremamente semplice capire quali sono i comandi che "muovono" il sistema, chi li manda e a chi. Sulla stessa falsariga é facile comprendere chi scatena eventi e soprattutto quali eventi scatena.

Data questa visione d'insieme il resto sono solo quisquiglie tecniche e tecnologiche di poco conto ;-)

Investire tempo ed energie per comprendere il dominio è il miglior sforzo che possiamo fare per dare una vera chance di successo al progetto.

.m