network profile
| bio | website | twitter.com/#!/gjbrits |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 10 months |
| seen | yesterday | |
| stats | profile views | 6 |
|
Jul 27 |
comment |
CQRS + Event Sourcing: (is it correct that) Commands are generally communicated point-to-point, while Domain Events are communicated through pub/sub? makes a lot of sense. Excellent analogy :) |
|
Jul 27 |
accepted | CQRS + Event Sourcing: (is it correct that) Commands are generally communicated point-to-point, while Domain Events are communicated through pub/sub? |
|
Jul 27 |
awarded | Tumbleweed |
|
Jul 25 |
awarded | Teacher |
|
Jul 20 |
awarded | Supporter |
|
Jul 20 |
asked | CQRS + Event Sourcing: (is it correct that) Commands are generally communicated point-to-point, while Domain Events are communicated through pub/sub? |
|
Jul 19 |
answered | DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? |
|
Jul 19 |
awarded | Scholar |
|
Jul 19 |
comment |
DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? you're right, thanks for answering the original. I'll take it up to the list |
|
Jul 19 |
accepted | DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? |
|
Jul 19 |
comment |
DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? ok that makes sense, but what I was getting at was, say the business rules dictate to go for an automatic solution. This solution entails to issue an event that contains a blogbody that is identical to what the blogbody of the blog would have been if the last BlogBodyChanged-event hadn't been saved. For this to work, the Aggegrate would need to be allowed to 'replay' itself until the point in time just before the last BlogBodyChanged-event happened, fetch the blogBody, wrap it in an activity and persist it to the activity store. The question: would this be an okay strategy? |
|
Jul 19 |
comment |
DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? Yeah I understand. "Revert" was probably ill-chosen. Consider the following: I might want to use Event Sourcing with Sagas for modeling, among other things, Document publishing / approval flows. What if an editor has send an ChangeBlogBody-action that is ultimately persisted as a BlogBodyChanged-event to the Event Store. Afterwards, for some reason, a Compensate Action is issued. How would the Aggregate know what compensate event to fire that results in the contents of the Blog Body as it was just before the ChangeBlogBody-action was issued? |
|
Jul 19 |
awarded | Student |
|
Jul 19 |
comment |
DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? How would the aggregate know to which state to revert? Would it be allowed to query against the event-store or something? |
|
Jul 19 |
asked | DDD, Saga & Event-sourcing: Can a Compensate Action simply be a delete on the event store? |
