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

Should we introduce specific annotations for Event Sourcing? #41

Open
StephanPirnbaum opened this issue Dec 18, 2020 · 3 comments
Open

Comments

@StephanPirnbaum
Copy link
Collaborator

It needs to be further discussed if we should add annotations specific for event sourcing, i.e.

  • the event itself
  • the handler and publisher of that event

This is continuing the discussion of PR #39

The addition of sourcing events would allow external tools (such as jQAssistant) to easily identify what are:

  • actual domain events that trigger a functionality in the same or another application
  • events used to enable the technical aspect of event sourcing

As mentioned in the PR, domain events have a domain specific context and thus may only model part of the data. Event sourcing events, on the other hand, do not limit the level of detail (e.g. credit card details would not be masked) and only contain changed data. Actual domain events may contain more information.

Also have a look into this article: https://www.innoq.com/en/blog/domain-events-versus-event-sourcing/

@OLibutzki
Copy link

It's more meaningful to have events which are used in a module locally and those which are published to the outside world. You can model the visibility by putting the event definition into the API oder implementation layer.

So in my opinion it's not necessary to have special semantics for domain events and event sourcing events.

@zambrovski
Copy link
Contributor

@OLibutzki this is very close to the discussion with @smcvb in Axon Discuss regarding the Local Event Store Support(https://discuss.axoniq.io/t/local-event-store-support/2980/19)... Marking event visibility seems to be a good thing... The only problem is, that you already introduced the DomainEvent concept here... And a pivotal event is probably not a domain event...

Do you have an idea how to resolve this?

@OLibutzki
Copy link

@zambrovski the linked issue is in a protected forum section, so the others cannot access it I fear.

Anyway, I don't think you necessarily need t mark them explicitly...

You can derive their scope from the actual usage.

If you want to introduce certain architectural constraints like It's not allowed to use a EventSourcingEvent/LocalEvent (you name it) outside of a module you need to have some assistence.

You can have a explicit annotation or interface, but you can also derive the information from the event's package, if you split up the api and the impl part.

There are a lot of options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants