Abbiamo toccato per la prima volta il problema quando abbiamo parlato della differenza tra eventi ed eventi di dominio per tornarci, grazie a Roberto, con un approfondimento e infine per lanciare la stoccata finale: I fat event non esistono.

Non abbiamo però mai detto che cosa sia un fat event.

Cosa sono

Un esempio vale mille parole, nel mondo Pub/Sub delineato da SOA un evento è (in pseudo codice json) una cosa del tipo:

{
   Id: ‘invoicePaidEvent/some-weird-unique-id’,
   InvoiceId: ‘the paid invoce id’,
   PaymentDate: ‘20161019’
}

Spesso invece trovo un evento come quello qui sopra definito come segue:

{
   Id: ‘invoicePaidEvent/some-weird-unique-id’, 
   PaymentDate: ‘20161019’,
   Invoice: {
      Id: ‘the paid invoce id’,
      Number: ‘…’,
      Date: ‘…’
   },
   Customer: {
      Name: ‘….’
      EtcEtc: ‘…’
   },
   SourceAccountIBAN: ‘…’,
   DestinationAccountIBAN: ‘…’,
   PaymentDelay: ‘…’
   OrderId: ‘…’
}

(Arriva da un progetto reale)
Un fat event è dunque un evento ricco di informazioni, spesso troppe informazioni.

Perché crediamo ci servano

Ora, è ovvio che prima di poter dire che una cosa è sbagliata o sbagliata in un certo contesto dobbiamo capire quali sono le motivazioni che ci portano a farne quello che io ritengo essere un uso sbagliato. Quello che vedo spesso è uno scenario come il seguente:

  • La UI permette all’utente di creare un ordine, ad esempio da un bel sistema di e-commerce
  • Durante la creazione dell’ordine l’utente immette anche l’indirizzo di spedizione della merce
  • L’endpoint che riceve la richiesta di creazione dell’ordine pubblica un evento “Ordine Creato”
    • evento a cui allega le informazioni sulla destinazione perché non sono di sua competenza ma sono di competenza di Shipping
  • Shipping si sottoscrive all’evento sia per iniziare il processo di spedizione ma anche per sapere quale sia l’indirizzo di spedizione

Abbiamo quindi la necessità di un fat event, “Ordine Creato”, al fine di condividere queste informazioni.

Gli eventi, nella concezione Pub/Sub SOA di evento, non servono per fare data sharing, ne tanto meno per rendere autonomo un servizio, che è una forma di data sharing se ci pensate. Quel fat event la sopra ha lo stesso problema di accoppiamento che avrebbe un’API pubblica.

Quindi? :-)

Post in questa serie: