A Napoli abbiamo parlato di “Services UI Composition” e per arrivare li siamo partiti dal problema che vogliamo risolvere problema inevitabilmente generato da una corretta implementazione dei dettami di SOA e DDD. Prima di tornare a parlare di “Services UI Composition”, argomento vastissimo e complesso, vorrei fare un escursus sul processo di modellazione che, se basato su DDD e SOA, porta a risultati che per alcuni possono essere inaspettati.
Fate un favore a voi stessi dimenticatevi la tecnologia, evitate cioè di cercare immediatamente una soluzione tecnologica a tutto quello che diremo, è controproducente. Inoltre ricordatevi che cosa è un servizio.
Il requisito
Uso il solito esempio trito e ritrito della vendita online, esempio che conosciamo tutti e dominio con cui in qualche modo abbiamo avuto a che fare.
State modellando il vostro bel sistema di e-commerce, il vostro UX architect si presenta con un mockup come il seguente per darvi un’idea delle informazioni che ritiene debbano essere presenti in una ipotetica lista prodotti:
Se doveste modellare un dominio che descrive il mockup di cui sopra quanti classi, e quali, definireste? O in altri termini quanti servizi SOA sono coinvolti in quella rappresentazione? o ancora quanti Bounded Context DDD? 1, 2 , 3…5…quante/i?