Quali sono le differenze tra il metodo di approvvigionamento degli eventi e il modello del livello di servizio?

3

Sto leggendo un libro sulle applicazioni aziendali di architettura. In questo libro viene introdotto il pattern Event Sourcing che può essere utilizzato come parte "comando" di un'architettura CQRS (Command and Query Responsibility Segregation). Event Sourcing è descritto da Martin Fowler come:

The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.

Sono abituato alle applicazioni che usano il pattern Service Layer, che descriverò come: le modifiche nell'interfaccia utente chiamano un metodo, che quindi attiva la chiamata di servizio appropriata in un livello middleware che delega la chiamata al back-end dove le informazioni sono aggiornato e notifica al chiamante il risultato.

Questa descrizione di un livello di servizio non mi sembra molto diversa da Event Sourcing.

Quali sono le differenze tra Event Sourcing e il modello Service Layer?

    
posta Erwin Rooijakkers 27.08.2015 - 11:55
fonte

2 risposte

2

Queste due cose non hanno molto in comune, tranne il fatto che anche nel modello di livello di servizio possono essere coinvolti alcuni "eventi". Ma è qui che finisce la comunanza.

  • nel "modello del livello di servizio", ci sono diversi livelli che si chiamano a vicenda e attivano alcune modifiche al sistema. Ma le chiamate non sono necessariamente "catturate nell'evento oggetti ", né le chiamate sono necessariamente memorizzate ovunque.

  • in Event Sourcing, non c'è necessariamente una notifica di ritorno al chiamante, che non fa parte dello schema

In realtà, un modo per implementare il sourcing di eventi è consentire al livello di servizio di prendere le chiamate dell'interfaccia utente, incapsularle negli oggetti evento e inviarle alla coda degli eventi. Il livello di servizio può anche provare a generare una notifica di risultato appropriata per l'interfaccia utente. Quindi questi due modelli possono funzionare perfettamente insieme, ma soprattutto perché sono ortogonali .

    
risposta data 27.08.2015 - 13:10
fonte
1

Per completare la risposta di Doc, gli eventi non sono intesi per restituire valori, questa sarebbe una violazione del modello CQS (separazione di comandi e query, ovvero lettura / scrittura). Catturano le intenzioni di business, creando una sorta di audit trail per tutto ciò che accade nel sistema. Possono essere l'unica fonte di dati nel sistema. In tal caso, potrebbe non essere più necessario disporre di un database (diverso dall'archivio eventi), poiché è possibile "montare" l'intero sistema nella RAM dall'archivio eventi e da uno stato iniziale. È anche possibile creare istantanee del sistema, data una data di riferimento. I PaaS ora supportano questo tipo di sistemi.

Il modello di servizio riguarda anche la definizione di ambiti e responsabilità limitati per i componenti che si stanno per sviluppare (riguardanti business e dati). Il modello di servizio consente ai componenti di gestire le query di lettura / scrittura.

    
risposta data 27.08.2015 - 18:28
fonte