> Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also. Indeed. These are two separate patterns. They can have great synergy when used together but it's not a requirement. > it's…
Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.
A proper event storage solution will have optimistic concurrency built in.
I feel like people are running into these problems because they want to pretend that a message broker is an event store. I could try to shovel a star schema into MongoDB too, but why would I want to? Keeping data only…
Why would it? Typically you would have one stream per user.
https://leanpub.com/esversioning/read
Best practices around this have already been established. Most if not all event stores - which Kafka is not - have a concept called 'position.' You save the position atomically along with whatever you did with the…
> Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also. Indeed. These are two separate patterns. They can have great synergy when used together but it's not a requirement. > it's…
Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.
A proper event storage solution will have optimistic concurrency built in.
I feel like people are running into these problems because they want to pretend that a message broker is an event store. I could try to shovel a star schema into MongoDB too, but why would I want to? Keeping data only…
Why would it? Typically you would have one stream per user.
https://leanpub.com/esversioning/read
Best practices around this have already been established. Most if not all event stores - which Kafka is not - have a concept called 'position.' You save the position atomically along with whatever you did with the…