We don't tend to use ARs, but achieve a similar effect (transaction boundary) with event streams. All use cases on the same event stream may not share the same model of state. For example, revoking an audit approval only needs to look through approve/revoke events and only needs to fold that into a state which keeps track of whether the audit is currently approved or not. Whereas other audit use use cases might examine all events from the same stream and replay into more detailed state. The dev can choose to share models between use cases. Having separate models for different use cases (on the same stream) is the standard DRY trade-off: repetition vs change isolation.
Yeah, I agree. That's a stereotypical event sourcing in DDD style - having an event stream per aggregate. It's exactly how I am describing it in the book as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can totally see that.
We don't tend to use ARs, but achieve a similar effect (transaction boundary) with event streams. All use cases on the same event stream may not share the same model of state. For example, revoking an audit approval only needs to look through approve/revoke events and only needs to fold that into a state which keeps track of whether the audit is currently approved or not. Whereas other audit use use cases might examine all events from the same stream and replay into more detailed state. The dev can choose to share models between use cases. Having separate models for different use cases (on the same stream) is the standard DRY trade-off: repetition vs change isolation.
Yeah, I agree. That's a stereotypical event sourcing in DDD style - having an event stream per aggregate. It's exactly how I am describing it in the book as well.