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

Event Storming Policies #38

Closed
jgozner opened this issue Feb 25, 2020 · 2 comments
Closed

Event Storming Policies #38

jgozner opened this issue Feb 25, 2020 · 2 comments

Comments

@jgozner
Copy link

jgozner commented Feb 25, 2020

Hey!

I just wanted to say thanks for such a great project. It's really helped me clear up questions that I've had around DDD. I just have one question regarding event storming and policies. Usually you would have the following flow in an event storming scenario.

event-storming

I'm trying to wrap my head around Policies and where to place the logic.

When a domain event is fired you would have a Notification to wrap that event and a NotificationHandler in the Application layer to handle the event. Where would you place the policy logic? In the NotificationHandler?

@kgrzybek
Copy link
Owner

Thank you for question @jgozner !

Firstly, let me quote nice explanation what policy is (from https://developer.ibm.com/technologies/java/tutorials/reactive-in-practice-1/):

Reactions (also known as policies) help to model system-initiated commands in response to events happening. For instance, we may want to initiate a command when something else happens. It’s this ‘when, then‘ notation that makes reactions very handy to use in modelling workshops. By convention, reactions are represented using lavender sticky notes. We can insert them between an event or a command, which makes it easy to model policies, with multiple commands being triggered from one event, or to attach the lavender sticky directly to a command, where a policy only has a single command associated with it.

Answering your question, in my opinion: policy logic should be placed in Event Handler when it is simple. When the logic is complex, this logic should be placed in your Domain (for example in Domain Service) and Event Handler should only delegate and coordinate this process.

There is one example of this very easy logic policy in this project:

  • Given Attendee is added to Meeting
  • When Fee is not empty
  • Then create a Meeting Payment
internal class MeetingAttendeeAddedIntegrationEventHandler : INotificationHandler<MeetingAttendeeAddedIntegrationEvent>
{
    private readonly ICommandsScheduler _commandsScheduler;

    internal MeetingAttendeeAddedIntegrationEventHandler(ICommandsScheduler commandsScheduler)
    {
        _commandsScheduler = commandsScheduler;
    }

    public async Task Handle(MeetingAttendeeAddedIntegrationEvent notification, CancellationToken cancellationToken)
    {
        if (notification.FeeValue.HasValue)
        {
            await _commandsScheduler.EnqueueAsync(new CreateMeetingPaymentCommand(
                Guid.NewGuid(),
                new PayerId(notification.AttendeeId), 
                new MeetingId(notification.MeetingId),
                notification.FeeValue.Value, 
                notification.FeeCurrency));
        }
    }
}

@jgozner
Copy link
Author

jgozner commented Feb 26, 2020

That makes so much sense! Thanks for taking the time to reply and explain that :)

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

No branches or pull requests

2 participants