mishudark / eventhus Goto Github PK

https://github.com/go-kit/kit

gokit only supports simple RPC.

I dont knwo if eventhus is dead, but it looks like it can pretty easily work with gokit.

MongoDB has a 16MB limit per document hard-coded, since eventhus uses a single document to store the events, there's a limitation there.

I would recommend using per-document events, instead of per-document aggregates, and you can still make that atomic by simply removing the if condition here and remove entirely this else statement.

Of course, a change to Client.Load() to do a findAll instead of findOne, and sorting by the version later. What you guys think?

probably wercker should be an interesting option

Currently trying to use this library gives me this error when running:

# github.com/mishudark/eventhus/eventstore/badger
../../../go/src/github.com/mishudark/eventhus/eventstore/badger/badger.go:120:12: assignment mismatch: 2 variables but item.Value returns 1 values
../../../go/src/github.com/mishudark/eventhus/eventstore/badger/badger.go:120:25: not enough arguments in call to item.Value
	have ()
	want (func([]byte) error)
../../../go/src/github.com/mishudark/eventhus/eventstore/badger/badger.go:175:22: assignment mismatch: 2 variables but item.Value returns 1 values
../../../go/src/github.com/mishudark/eventhus/eventstore/badger/badger.go:175:35: not enough arguments in call to item.Value
	have ()
	want (func([]byte) error)

What's interesting is that when I try to run the example bank application from a cloned github repo, it works fine. But if I separate the example from the repo folder or make my own implementation, I constantly get this error.

I see your code and you do not publish event to MQ and saving to DB Atomically.
This mean that is a service fails before sending an event, no one will be notified

Hi,
I'm using your repo as a foundation to implement event-sourcing. While experimenting with it I faced with following issues:

1. Why it should not be possible to create an event without to specify a version in the command? Other event-store libs like https://github.com/envato/event_sourcery provide the exact version match optionally.
2. For every aggregate, we need to set the ID

   eventhus/examples/bank/account.go

   Line 24 in d39839f

   a.ID = event.AggregateID

   the same for

   eventhus/examples/bank/account.go

   Line 41 in d39839f

   event.AggregateID = c.AggregateID

   . This can be easily abstracted.

Btw: Are you using this lib in production? There is a lot of room for improvements (error handling in commandbus, retry-mechanism, graceful shutdown of connections, logging). From my understanding, this project is just a playground for you right?

I could solve most of the issues and implemented a SQL integration with https://gorm.io/. If anybody is interested in it I will take the time to create a PR against v2.

Hi, I'm trying to experiment with your repo but I run into

How should it work? How can I create the initial aggregation event?

As I understand a 'canonical' CQRS-ES pattern reading clients are encouraged to maintain there own view models, optimized for their use case. A reading client would subscribe to the event queue and build it's view model based on the events it's receive.

The CQRS-ES pattern does not dictate the nature of this view model:

• if a reading client is keeping the state of the entire domain, a single domain entity.
• if it keeps all information or a specific subset
• if it keeps the information inevitably, or just keep it for the duration of a session.

Keeping a local copy of a single aggregate as well as keeping a syncronized (read only) query db is equally valid use cases from the reading client.

I am going to look at a view model representing a single uniquely identifiable aggregate. It could equally well be a set of such aggregates, the entire DDD, it does not matter. The reading client might join the CQRS-ES entwork at any time, meanting that we don't initially know the state of the aggregate. Looking at the life-cycle of my view-model / aggregate there are the following situations.

1. When a new aggregate is created. The client can safely assume that it is creating a new unique aggregate. It will issue a new command using a new aggregate id and version 0.
2. When the aggregate exist in the view model. The next command created will use the existing aggregate id and version.
3. When the command have failed, indicated an invalid (outdated) version: The client will need to catch up with the history of the aggregate.
4. When the client have the id of the aggregate but no view-model: The client will need to catch up with the history of the aggregate.

So far I assumed that the aggregate have a unique id that I have. This happens to be safe for the application that I am currenly building. It is also possible that the aggregate can additonally be identified by a natural key that also uniquely identifies the aggregate. The CQRS-ES pattern propose a reading client building an index (mapping natural key to aggregate id) to care for these situations. To care for building the index there is also the following situation.

5. When the client does not have the aggregate key and can not safely assume that the aggregate does not exist. Look up the aggregate, bootstrap the index: retrieve all aggregates with all events.

For now I am mostly interested in (3.) and (4.). How do the client get all the events of an existing aggregate? The client have the aggregate id, but does not have an up to date view model.

I would want the account example to cover cases (3.) and (4.). How should the client retrieve all (missing) events given an aggregate id?

The use of context is a must to have with Go v1.7.4+ and it should help to cancel long running process according the developer needs

I see EventBus has publish but not a subscribe?
Just curious how the events propagated to projects for querying?
I apologize if subscribe is defined somewhere else as I did not read the source code completely.