Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event sourcing support #8

Open
roblaszczak opened this issue Nov 18, 2018 · 4 comments
Open

Event sourcing support #8

roblaszczak opened this issue Nov 18, 2018 · 4 comments

Comments

@roblaszczak
Copy link
Member

@roblaszczak roblaszczak commented Nov 18, 2018

No description provided.

@olpie101
Copy link

@olpie101 olpie101 commented Dec 22, 2018

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.

@roblaszczak
Copy link
Member Author

@roblaszczak roblaszczak commented Jan 2, 2019

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 :)

@roblaszczak
Copy link
Member Author

@roblaszczak roblaszczak commented Sep 16, 2019

In progress! :) I will publish some proof of concepts soon.

@roblaszczak roblaszczak mentioned this issue Sep 16, 2019
0 of 2 tasks complete
@roblaszczak roblaszczak added the L label Sep 16, 2019
@blaggacao
Copy link

@blaggacao blaggacao commented Nov 9, 2020

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:


Since one command may result in several events, it is also important never to persist only some events that result from executing a command. And so events must be appended to the event store in a single atomic transaction, so that if some of the events resulting from executing a command cannot be stored then none of them will be stored.

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
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants