Alessandro Melchiori da qualche settimana millanta che avrebbe scritto dei post inerenti all’argomento Services UI Composition, ecco millanta :-D

Forza Ale pubblica qualcosa!

Per cercare di smuovere ancora un po’ le acque sto preparando una nuova sessione che al momento è così definita:

Tutti i nostri aggregati sono sbagliati

Inizia sempre tutto bene, il requisito è semplice e l'implementazione procede senza intoppi. Poi i requisiti aumentano e ci ritroviamo con una strana sensazione allo stomaco e con la necessità di introdurre alchimie tecnologiche che non ci piacciono, ma non sappiamo perché.

Prenderemo una funzionalità tanto semplice, quanto usata, come il carrello di un e-commerce e proveremo a capire se è veramente così semplice. Guarderemo il problema tecnico che volgiamo risolvere e poi sposteremo l'attenzione sui requisiti di business. Requisiti che una volta compresi a fondo ci porteranno a capire quali sono le vere responsabilità del dominio.

Diciamo che il primo obiettivo è stimolare il solito Melchiori a scrivere, il secondo è più nobile e parte dal seguente snippet di codice:

var order = repository.GetById<OrderAggregate>( 44 );
order.Ship();
repository.CommitChanges();

Non vi suona male?

Provate a leggere in italiano quello che c’è scritto li, io leggo:

Archivio dammi l’ordine 44, ordine 44 spedisciti.

Quel design secondo me è conseguenza di un errore. L’errore di fondo è che pensiamo prima al problema tecnologico e poi forse a quello di design.

Diciamocela tutta: un ordine non si spedisce da solo.

Quando ci hanno detto Data & Behavior la & ci ha fatto sbombare il parser e ci siamo fermati a Data, un po’come i famosi hack dei CSS per far digerire a IE robe che non digeriva :-)

Inoltre quel design, dal punto di vista SOA, comporta un altro problema: mischia le carte in tavola in termini di responsabilità. Supponendo che un ordine sia in grado di spedirsi da solo, al fine di poterlo fare dovrebbe:

  • sapere dove spedirsi e a chi
  • sapere come spedirsi

Entrambe le cose non credo siano di competenza dell’ordine.

Obiettivo della sessione sarà proprio spingere l’acceleratore su come SOA disegna il modello di dominio.