4 ms·

They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is

by dm3 5y ago

They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is not a part of Event Sourcing.

oskar_dudycz 5y ago
I think that they were just building the stale read models, and used them as the write model, which created the whole confusion. Regarding the sharing events between module, it's one of the most common and the most dangerous mistakes. It's a leaking abstraction that will eventually create a distributed monolith. It has only downsides of monolith and microservices, without the upsides. I wrote longer on the topic of internal and external events, and how to model them: https://event-driven.io/en/events_should_be_as_small_as_possible/ https://event-driven.io/en/events_should_be_as_small_as_poss...
- nhumrich 5y ago
  What you are talking about is CQRS, which is a very valid pattern, and pairs well with event sourcing, but is not necessary part of event sourcing. You don't have to split your read and write models for events sourcing.
  - oskar_dudycz 5y ago
    Could you elaborate, I think that I'm missing your point.
nhumrich 5y ago
I am confused when you say sharing events isn't part of event sourcing. How does a service populate it's state from other services event source if it can't access it's events?
- oskar_dudycz 5y ago
  Did you read my article that I linked, or my initial explanation of the Event Sourcing flow?
- tomnipotent 5y ago
  > How does a service populate it's state from other services event source if it can't access it's events? Because it's the source of the events and its own system of record. If an event sourced app wants to share events, it should not be re-using internal events but creating new items intended for distribution just like you would with any other distributed system (thrift/protobuf over Kafka).

by dm3 5y ago

They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is not a part of Event Sourcing.

oskar_dudycz 5y ago

I think that they were just building the stale read models, and used them as the write model, which created the whole confusion. Regarding the sharing events between module, it's one of the most common and the most dangerous mistakes. It's a leaking abstraction that will eventually create a distributed monolith. It has only downsides of monolith and microservices, without the upsides. I wrote longer on the topic of internal and external events, and how to model them: https://event-driven.io/en/events_should_be_as_small_as_possible/ https://event-driven.io/en/events_should_be_as_small_as_poss...

nhumrich 5y ago
What you are talking about is CQRS, which is a very valid pattern, and pairs well with event sourcing, but is not necessary part of event sourcing. You don't have to split your read and write models for events sourcing.
- oskar_dudycz 5y ago
  Could you elaborate, I think that I'm missing your point.

nhumrich 5y ago

I am confused when you say sharing events isn't part of event sourcing. How does a service populate it's state from other services event source if it can't access it's events?

oskar_dudycz 5y ago
Did you read my article that I linked, or my initial explanation of the Event Sourcing flow?
tomnipotent 5y ago
> How does a service populate it's state from other services event source if it can't access it's events? Because it's the source of the events and its own system of record. If an event sourced app wants to share events, it should not be re-using internal events but creating new items intended for distribution just like you would with any other distributed system (thrift/protobuf over Kafka).