Siamo partiti da questa immagine:
Partendo dall’assioma che rappresenti un requisito espresso da uno stakeholder non tecnico, ad esempio un product owner o una porzione dell’information flow frutto di una analisi di user experience.
Kudos a Luca che accoglie la sfida e ci prova:
Io direi un ViewModel principale (che so ProductsViewModel) ed una serie di template in base a diversi fattori : origine dei dati, prospettive di evoluzione della UX, necessità di rendering, etc...
È sbagliato? non necessariamente, è giusto? non necessariamente :-) dipende? non direi, diciamo che c’è una risposta giusta e poi tutta una serie di compromessi. I compromessi in se non sono di certo il male, l’importante è sapere dove si è fatta una scelta che deve essere etichettata come un compromesso in modo da sapere che li potremmo avere un problema in futuro.
Modello mentale
Proviamo ad immaginare un modello basato su un ViewModel, il ProductsViewModel di Luca ad esempio, e calarlo in una azienda reale, Acme S.r.l.. Qualcuno in Acme è responsabile per la gestione prodotti, ha cioè la ownership di quel concetto, se già fossero più persone da dipartimenti diversi abbiamo un problema perché stiamo violando uno dei principi fondamentali dei Bounded Context.
In Acme c’è quindi un ufficio sulla cui porta c’è scritto “gestione prodotti”, arriva l’omino del magazzino e dice:
guarda che il prodotto 123 non è più disponibile, quindi non lo possiamo più vendere
A questo punto l’omino della gestione prodotti va dall’omino della gestione contratti e gli dice:
mi ha detto “magazzino” che il prodotto 123 non è più disponibile quindi tutti gli ordini che hai in corso sono da annullare
Nel frattempo fuori dalla porta di “gestione prodotti” si è formata la coda, c’è “marketing” che:
vuole cambiare la descrizione di un prodotto attualmente in vendita ma lo vuole fare da settimana prossima, martedì alle 13, e lo vuole solo per la parte in inglese
C’è anche “vendite” che
vuole attivare una nuova promozione per tutti i prodotti della categoria XYZ venduti insieme al prodotto 456 se comperati da qualcuno in provincia di Milano, ovviamente la promozione è valida solo per ordini sopra una certa cifra fatti un determinato periodo
Infine c’è “ricerca e sviluppo” che
vuole mettere in vendita un prodotto che non esiste a magazzino per testare, tramite le statistiche, se è interessante o meno per il navigatore del sito
“gestione prodotti”, dopo aver ascoltato tutti, si alza e si licenzia :-)
Troppe responsabilità
Può funzionare? certo che può, ma ve la immaginate una classe Prodotto che gestisce tutte quelle casistiche e tutte le altre che vi possono venire in mente in uno scenario reale?