Questo è stato forse il concetto che maggiormente è cambiato nella mia mente dopo il #csddd. Se questa domanda mi fosse stata posta prima del campus, molto probabilmente la risposta sarebbe stata:
Quando ho un dominio complicato, con regole che cambiano spesso.
Questa definizione è in realtà fuorviante, la risposta che darei ora è
Quando sono in un dominio che conosco poco, ho bisogno di sperimentare e voglio principalmente capire il problema che andrò a risolvere.
Quello che cambia è il focus, che sta nel capire il problema, ovvero cercare di comprendere il business che dovremo modellare con il software; focalizzare realmente il dominio del problema per riuscire a capire dove “sta la ciccia” (termine tecnico utilizzato a più riprese da ZioBrando :) ). Non a caso l’UBIQUITOUS LANGUAGE è l’inizio del Blue Book di Evans ed è un concetto assolutamente non tecnico, un unica lingua con cui far comunicare chi deve realizzare il software, con gli esperti di dominio senza ambiguità.
In sostanza l’UBIQUITOUS LANGUAGE serve a far si che quando io parlo con l’esperto di dominio e dico “Quando assegno una spada ad un Mago questo deve essere impedito perché i Maghi non possono usare spade, a meno che il Mago non stia utilizzando un oggetto magico, che gli permetta l’uso di armi normalmente a lui non permesse”, stiamo parlando entrambi degli stessi concetti. Lo scopo dell’UBIQUITOUS LANGUAGE è far si che il significato dei termini in neretto sottintendano lo stesso concetto per l’esperto di dominio e per i tecnici. Non è assolutamente necessario che nel codice esista per forza una classe Mago (potrebbe non esistere o ancora più comunemente ne esisteranno molte), ma è necessario che entrambe le parti pensino allo stesso concetto reale quando sentono i termini Spada o Mago.
Un altro concetto molto importante è quello di cercare di sviscerare le parti che non si conoscono. Quando si decide da dove iniziare a ragionare con gli esperti di dominio, la scelta deve cadere nelle parti che conosciamo di meno, sia perché potenzialmente nascondono i rischi maggiori, ma anche perché partendo da un livello basso di conoscenza, con poco abbiamo già un grande vantaggio.
Quindi possiamo affermare che l’approccio del DDD primariamente mira a creare una consapevolezza/conoscenza comune del problema allo scopo di annullare le ambiguità e permettere una graduale esplorazione delle possibili soluzioni.
Gian Maria.