Event sourcing support #8
Comments
Hello, I am keen on contributing. I am wondering if there are any design ideas for this component, that could form the basis of an initial discussion and/or implementation. |
Hello @olpie101. For this moment there aren't any written concept yet. If you have some ideas or sources feel free to post it here :) |
In progress! :) I will publish some proof of concepts soon. |
Eventstore: https://dgraph.io/badger See implementation for event sourcing: https://github.com/mishudark/eventhus/blob/master/eventstore/badger/badger.go https://github.com/timshannon/badgerhold (for convenient read models) Plus Polling-Publisher Message Relay https://microservices.io/patterns/data/polling-publisher.html It also seems this might be a bit tricky with the current CQRS implementation:
Source: https://eventsourcing.readthedocs.io/en/v3.0.0/topics/user_guide/aggregates_in_ddd.html It seems this is the most compatible pattern I have found so far with watermill's cqrs implementation: https://github.com/andrewwebber/cqrs Specifically, since their implementation does not require handler in the form of aggregate methods, but uses plain old handler functions: func(command cqrs.Command) error {
changePasswordCommand := command.Body.(ChangePasswordCommand)
// Load account from storage
account, err := NewAccountFromHistory(changePasswordCommand.AccountID, repository)
if err != nil {
return err
}
account.ChangePassword(changePasswordCommand.NewPassword)
// Persist new events
repository.Save(account)
return nil
} |
No description provided.
The text was updated successfully, but these errors were encountered: