You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On page 24, there is a recordApplyAndPublishThat method mentioned, that calls the recordThat method and the applyThat method. Should the recordThat method not simply call the applyThat method? Or is there a reason to ever record an event without applying the changes on the aggregate?
The text was updated successfully, but these errors were encountered:
Major frameworks like Prooph and Broadway do it as described by @MetalArend : the method for recording an event directly calls the method for updating the internal state.
recordThat() records the event, and calls when() which then calls the method that updates the aggregate's internal state.
I'm also wondering why the aggregate in the book has a publish() method. Both Broadway and Prooph delegate publishing/dispatching of events to the persistence layer (repository or event store class) by injecting a publisher there, because it reduces the risk that an event would not be persisted because of concurrency issues but still be published to the event bus (which would result in incorrect read models being created).
On page 24, there is a
recordApplyAndPublishThat
method mentioned, that calls therecordThat
method and theapplyThat
method. Should therecordThat
method not simply call theapplyThat
method? Or is there a reason to ever record an event without applying the changes on the aggregate?The text was updated successfully, but these errors were encountered: