Side effects event sourcing

Question

I create a service using the usual event search pattern:

• Request received.
• The general story is loading.
• The unit is rebuilt (from its history).
• New events are prepared, and the unit is updated in response to an incoming request from step 1.
• These events are logged and made available (published) to all subscribers.

In my case, step 5 is performed in two parts. Events are recorded in the event log. The background process is read from the event log and publishes all events starting at the offset.

In some cases, I need to post side effects in addition to aggregate events. As for the system, these are events, because they are consumed and affect the state of other services. However, they do not affect the history of the population in this service and are not needed to restore it.

How do I handle them in code?

Option 1- Do not write side effects to the event log. Publish them in the main process until step 5.

Option 2- Write everything to the event log and ignore the side effects when loading the story. (This is not part of the story!)

Option 3- Record side effects in a fictitious aggregate so that they are published but never loaded.

Option 4-

The first option may cause problems if there is a concurrency violation. If the recording fails in step 5, a side effect cannot be easily rolled back. The second option records events that are not part of the overall story. When loading in step 2, these side effects should be ignored. The third option looks like a hack.

Which one seems right to you?

Answer 1

Correct event names

Events are "things that happened." So, if you can name events that only trigger “X” style side effects, they become a natural part of the story.

In my experience, this is always possible because side effects do not come from the air. Sometimes a name becomes a little artificial, but it’s even better to name the events in such a way as to name them, for example. "send email to this customer event."

From the point of view of your list of alternatives, this will be option 2.

Example

Instead of raising the "send email status to client event" event, name it "email triggered event". Of course, if there is a better name for the actual trigger, use it :-)

Answer 2

Option 4 - Ask another service to subscribe to events and produce side effects, as well as any additional events associated with them.

Events must be fine-grained.

Answer 3

Option 1 - Do not write side effects to the event log. Publish this in the main process until step 5.

What if you later need this part of the story by creating a new limited context?

Option 2. Write everything in the event log and ignore the side effects of the event when the story is loaded. (This is not part of the story!)

How to ignore the effect of something that has no effect ?: D

Option 3- Write side effects to the dummy aggregate so that they are published but never loaded.

Why do you need a boundary of coherence around something that you will never change?

What you are talking about is the most common form of domain event that you use to communicate with other BC-s. Ofc. you need to save them.