xmolecules/jmolecules

Should we introduce specific annotations for Event Sourcing?

Opened this issue · 3 comments

StephanPirnbaum commented

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 commented

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.

  • 👍2
zambrovski commented

@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 commented

@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.