La domanda di Fabio mi spinge a trattare subito IT/Ops:
immagina una ui che vede dal canale di lettura una projection di nome SuperOrder che è un mix di quello che server side avviene a fronte dell'evento dal canale di scrittura di OrderUpdated\Created and CustomerUpdated\Created e dalle quali viene creata una denormalizzazione che confluisce in SuperOrder
tutto chiaro, il “problema” è che se scegliamo Services UI Composition come strada una
projection risultato un mix tra quello che succede in servizi diversi non esiste, a meno che non ci sia uno specifico caso d’uso (e ce ne sono, ergo questo post).
A questo punto la UI deve fare un update di SuperORder utilizzando il comando di un BC UpdateOrderCommand e di un'altro BC UpdateCustomerCommand senza aver mai conosciuto la "forma" dell'Order e del Customer del canale di scrittura e magari non avendo tutti i dati a disposizione dal momento che la projection potrebbe non esporli tutti.
In realtà li conosce ma ancora in realtà non è la projection che li conosce.
Usiamo un caso reale
Ad un certo punto del processo gli ordini devono essere spediti, per fortuna direte voi, e per spedirli usiamo un corriere espresso. Il nostro corriere di fiducia oltre a sapere dove spedire vuole anche un paio di informazioni in più:
- Ingombro dei colli
- valore della merce
- eventuali contenuti speciali, come ad esempio roba chimica etc..
Se ci pensate quelle tre informazioni non sono parte dell’ordine e non vengono neanche de-normalizzate all’interno dell’ordine, come ad esempio il prezzo del prodotto acquistato., come facciamo quindi in fase di generazione della spedizione a mandarle al corriere?
IT/Ops
Shipping è responsabile di generare l’ordine di spedizione, diciamo che questo avviene con una chiamata ad un servizio remoto esposto dal corriere di turno, diciamo anche che il servizio remoto si aspetta un payload xml con tutte le informazioni dell’ordine più le informazioni di cui sopra.
Come abbiamo detto in questa comunicazione devono in qualche modo partecipare anche Warehose e Sales, o Finance che dir si voglia, ma lo devono fare al solo scopo di arricchire il payload, che se ci pensate è una projection per come lo vede il corriere.
Ci sarà qualcuno che media, ACL, la comunicazione, questo qualcuno ospiterà (in termini tecnici farà hosting di assembly) i componenti di Sales e Warehouse che sanno come si fa ad arricchire il payload per quel corriere specifico.
Abbiamo generato una projection, l’abbiamo fatto senza usare fat event, e se proprio ci servisse lo potremmo fare usando messaggi. Se pensate a quello che abbiamo appena detto vi immaginate immediatamente che uno di quei component parli direttamente con il servizio di sua competenza, non c’è nulla di male. Una projection condivisa/mista, o IT/Ops che dir si voglia, genera per forza accoppiamento. È ovvio che al crescere dei component coinvolti l’accoppiamento temporale, o banalmente la rete scadente, fanno si che sia impossibile spedire perché tutti gli attori devono essere in grado di fare il lavoro richiesto nello stesso momento, ma nulla ci impedisce che i componenti in maniera trasparente rispetto all’ACL che li ospita si comportino in maniera più interessante:
L’accoppiamento c’è comunque ed è inevitabile in scenari come questo.
C’`e un altro caso, lampante, in cui una projection mista sembra essere l’unica soluzione, ma non è detto che lo sia. Ne parleremo.
Un’ultima considerazione: il fatto che in letteratura non esista il concetto di “projection mista” mi aiuta a pensare che non sia una cosa realmente necessaria.
Post in questa serie: