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 · 5 comments
Open

Event sourcing support #8

roblaszczak opened this issue Nov 18, 2018 · 5 comments
Labels
enhancement New feature or request L large issue module: components

Comments

@roblaszczak
Copy link
Member

No description provided.

@olpie101
Copy link

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

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

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

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

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
}

@dronezzzko
Copy link

@roblaszczak any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request L large issue module: components
Projects
None yet
Development

No branches or pull requests

4 participants