search

envato / event_sourcery

A library for building event sourced applications in Ruby
MIT License
84 stars 10 forks source link

Validate events on sink #176

Closed macosgrove closed 7 years ago

macosgrove commented 7 years ago

This PR is a replacement for https://github.com/envato/event_sourcery/pull/174 and https://github.com/envato/event_sourcery-postgres/pull/36.

See the discussion there around best time to validate events.

Here I'm validating on sink rather than on apply_event and emit_event.

Is there a risk here of action being taken on receiving or creating an invalid event, before that event is stored? Do we need to validate in more than one place? What do you think?

macosgrove commented 7 years ago

These are the scenarios I worry about:

1) Command is issued. 2) Details are passed to an aggregate 3) Aggregate takes some action with a side effect - eg posting to a third party service 4) Aggregate asks the repository to sink the event indicating it had taken that action 5) Event validation fails

and

1) Reactor reads an event 2) Reactor takes some action in response, with a side effect - eg posting to a third party service 3) Reactor tries to emit an event indicating it had taken that action 4) Event validation fails

grassdog commented 7 years ago

Hmmm, you control the code in both cases and I'd say it's the responsibility of that code to ensure the event it's producing to record that its taken an action is valid. You could call valid? yourself in there before taking action if you're worried.

If the event has an attribute that comes from some result of taking action you'll likely need a sensible fallback for what to place in that attribute if the action succeeds but doesn't reliably provide it to you (or just don't make the attribute mandatory in that case).

If the validation rules on the event change you'd want to make sure you found any code that violated that before you deploy that change. That should be highlighted by a test as the sink would fail if you added a new mandatory field to the event for example.

stevehodgkiss commented 7 years ago

I agree with @grassdog. This should probably be an application specific thing rather than something built into Event Sourcery. Let's discuss this further in Monday's session.

macosgrove commented 7 years ago

I'm closing this pull request after discussion in the brown bag. Will do something similar in a new gem along the lines of the open source "Contrib" piece of Apache as Leon suggested.