Vorrei lanciare un’altra provocazione, simile a i “fat event” non esistono: ci serve veramente il modello in lettura?
Non ne sono più così sicuro. Seguitemi.
Se modelliamo il nostro requisito affidandoci alla consistenza eventuale come unica soluzione del problema, allora si abbiamo bisogno sia dei fat event che delle projection.
Ma se la composizione delle informazioni avviene a livello di UI, è la UI stessa che rappresenta la projection in questione; riprendiamo un esempio che abbiamo già usato:
Ora, tentazioni.
La prima tentazione è di avere, nel nostro mondo, una cosa del tipo:
{
ProductId: “”,
ImageUrl: “”,
Delivery: {
Date: “”,
Status: “”,
Address: “”,
Steps: [ … ]
},
OrderId: “”,
OrderDate: “”,
ShipmentDate: “”
}
Quella qui sopra è una projection atta a soddisfare il bisogno della UI. Non c’è nulla di sbagliato, la domanda è: ci serve veramente?
Probabilmente no.
Se abbiamo decomposto correttamente il nostro mondo probabilmente no. Possiamo modellare la pagina li sopra lasciando che ognuno dei servizi sia responsabile delle informazioni che gestisce e lasciando che sia la pagina a comporre quello che vediamo:
Quello che stiamo guardando è lo stato di una spedizione
{
ShipmentDate: “”,
DeliveryAddress: “”,
OrderId: “”,
ProductId: “”
}
Quando è stato spedito e cosa; in base a cosa possiamo recuperare le informazioni che ci servono sull’odine:
{
OrderId: “”,
OrderDate: “”,
ProductId: “”,
}
e le informazioni sul prodotto
{
ProductId: “”,
ImageUrl: “”
}
infine le informazioni sullo stato della spedizione:
{
OrderId: “”,
Delivery: {
Date: “”,
Status: “”,
Steps: [ … ]
}
Ovvio che il titolo è provocatorio e probabilmente ovvio che i piccoli modelli definiti in questo post sono a loro volta delle projection che danno una visione parziale e atta a soddisfare il requisito in questione. Come ho già avuto modo di dire le projection miste sono uno smell.
Ci sono dei casi in cui probabilmente sono un male necessario. Stay tuned.
Post in questa serie: