Open SpareShade opened 2 years ago
The reason why I did that is because with the message bus I am using the context is not carried over
Thank you for getting back on this question.
But aren't the events handled first by the repository, which then publishes them to the event bus? The repository should still have access to the request context, or is this not so.
// Save current user changes to event store and publish each event with an event bus
func (r *userRepository) Save(ctx context.Context, u user.User) error {
if err := r.eventStore.Store(ctx, u.Changes()); err != nil {
return apperrors.Wrap(err)
}
for _, event := range u.Changes() {
if err := r.eventBus.Publish(ctx, event); err != nil {
return apperrors.Wrap(err)
}
}
return nil
}
I don't mean to nitpick. I'm just drawing a lot from your code (very nicely written too), and want to see whether there are potential pitfalls in my implementation/thinking. And of course, it's best to think together :)
yes you are right! i suppose i have missed that. i agree it would feel much better in the repository instead of having this in the domain. would you like to contribute and move it yourself? i would happily merge your pr :) and it feels like an easy change
Yes, I can absolutely, glad you agree :).
I am tied up atm, but should have a gap next weekend, it won't be too long in any case :)
ok cool, will w8 ;)
Hello @vardius
Thank you for sharing this library, it is very helpful in many regards!
My question is about your choice of appending the metadata in the aggregate itself. Eg.
Seeing the
UserAgent
orIP
exposed in the aggregate feels a bit like pollution of a domain with application/infra data. I understand that the aggregate essentially proxies this data from the command handler, which usually is acceptable practice, as aggregate is not making use of that data.I am wondering if you would not mind sharing your thoughts as to why you chose to enrich the event in the aggregate as opposed to eg. in the aggregate repository implementation.
Thanks again for sharing!