What are the differences between Event Sourcing and Service Layer pattern?

Question

I am reading a book on architecting enterprise applications. In this book the Event Sourcing pattern is introduced which can be used as the "command" part of a Command and Query Responsibility Segregation (CQRS) architecture. Event Sourcing is described by Martin Fowler as:

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.

I am used to applications that use the Service Layer pattern, which I would describe as: changes in the UI call a method, which then triggers the appropriate service call in a middleware layer which delegates the call to the backend where information is updated and notifies the caller of the result.

This description of a Service Layer does, to me, not seem very different from Event Sourcing.

What are the differences between Event Sourcing and the Service Layer pattern?

Answer 1

Those two things do not much have in common, except the fact that also in the Service Layer pattern some kind of "events" may be involved. But that is where commonalities end.

• in the "Service Layer pattern", there are different layers calling each other and triggering some system change. But the calls are not necessarily "captured in event objects", nor are the calls necessarily stored anywhere.

• in Event Sourcing, there is not necessarily a result notification back to the caller, that is not part of the pattern

Actually, one way of implementing Event sourcing is to let the service layer take the UI calls, encapsulate them in event objects and feed them to the event queue. The service layer can also try to generate an appropriate result notification for the UI. So these two patterns can work perfectly together, but mostly because they are orthogonal.

Answer 2

To complete Doc's response, events are not meant to return values, this would be a violation of the CQS pattern (separation of commands and queries, aka read/write). They capture business intentions, creating a kind of audit trail for all that happen in the system. They can be the only data source in the system. In that case, there may be no need to have a database anymore (other than the events store), as it is possible to "mount" the entire system in RAM from the events store and an initial state. It is also possible to create snapshots of the system, given a reference date. PaaS do now support that kind of systems.

The service pattern is also about defining limited scopes and responsibilities for the components you are about to develop (concerning business and data). The service pattern allow components to handle read/write queries.