General Modeling Question

[reify-joe-eckard]

Thanks for making this library available, I've enjoyed reading your blog posts. One thing I am struggling with is how to model / implement a decider that needs information from another decider / aggregate to determine if a command is valid.

Is it reasonable to assume that EventRepository.fetchEvents(c) can use IDs from the command to fetch events from multiple deciders and combine them into one stream used to build up state for the decider?

Expanding on your restaurant example, let's say I wanted to track the preparation of order items as a prescribed series of steps are taken.

• Each Restaurant MenuItem now has a configurable series of steps.
  • A step may depend on other steps.
  • Steps with no dependencies can be started at any time and can be performed in parallel.
• Each OrderLineItem may now have a status for each step e.g. IN_PROGRESS, COMPLETED or FAILED.

(for simplicity's sake let's assume that multiple quantities will start/complete together and ignore failures)

Commands are expected such as StartStep & CompleteStep which contain an orderLineItemId and a stepId.

To determine if a command is valid a decider needs to know:

• For this OrderLineItem, which steps are currently in progress / completed?
• Does this step have prerequisites?

Does that mean fetchEvents could fetch MenuItem step events for the supplied stepId as well as OrderLineItem step status events for the supplied orderLineItemId and use those to compute a new state that can be used to answer the above questions? (This also assumes that MenuItem step events are produced when creating a restaurant or changing a menu)

Also, would these commands ideally be handled by the Order decider, or a new, separate decider - something like OrderLineItemStepDecider?

Or am I completely off and this should be avoided and instead handled by independent deciders & Sagas somehow?

[idugalic]

Hi @reify-joe-eckard, thanks for your question, and your contribution!

Independent deciders can fetch only their own events (by deciderId for example). They should not use foreign events (of other deciders) to make the next decisions/events. It can easily leak and you would let foreign processes influence your decision with the events you don't control/create.

Please check this blog post

Deciders are modeling the process(es) in your business.
In this blog post, we start with the simplest case: One Decider to model all processes in the Restaurant

One Decider to model all processes in the Restaurant

A single Decider component is producing these events, representing a decision-making algorithm for the whole information system.

Pros

• We have a straightforward, linear model of the process, and this just might work for you - Simple!
• Every command (eg. PlaceRestaurantOrderCommand ) can easily be validated based on the current state and on the rules required: "I can only place an order if the items are on the Restaurant Menu"

Cons

• Commands for the single decider (deciderId) are handled sequentially (EventSourcingLockingAggregate), and having only one Decider( restaurantId ) can cause high contention in our pipeline. Imagine millions of orders queuing on that pure (single decider). It is not enabling parallelization. This problem is of technical nature.

Split to multiple deciders

In more complex situations, we tend to split a single process into multiple processes

Now you have two deciders (Restaurant and Order) and a Saga (visualized as a geer on event modeling blueprint) to coordinate them. Please focus on the PlaceRestaurantOrder command. It belongs to the Order. This command can result in a ResturantOrderCreated event which will awaken Saga and send a ValidateOrder command to the Restaurant decider ("are order items on the Restaurant menu", for example).

You have the option to

• scope both deciders and the saga into a single IEventSourcingOrchestratingLockingAggregate or IEventSourcingOrchestratingAggregate
• distribute deciders via independent IEventSourcingLockingAggregate and saga via SagaManager to deploy them independently.

Unfortunately, we don't have a demo application to demonstrate this.

Please refer to the https://fraktalio.com/blog/able-to-be-aggregated.html

Pros

• Distribute deciders and scale them independently
• Archive a greater degree of parallelization and concurrency
• Understand them better
• Test them easier
• Achieve Decider As A Service (DaaS) or Function As A Service (FaaS)

Cons

• It is introducing complexity

[reify-joe-eckard]

Ah, I see - this makes sense, thanks!

[reify-joe-eckard]

Would you ever selectively load events to build a partial state for a command - for example, if the restaurant menu was prohibitively large, and you didn't want to load it entirely for ValidateOrder? Or is this also a cue to split the process & use sagas?

In this case maybe a MenuItem decider that handles ValidateOrderItem commands to produce OrderItemValidated events?

[idugalic]

This is an interesting question! "Would you ever selectively load events to build a partial state for a command - for example"

The Restaurant (RestaurantMenu`) decider will load/eventsource all the events to build the whole restaurant state before the command is handled and new event(s) is/are published. This is easy and simple.

Sometimes, you don't have to load all events for the Restaurant/RestaurantMenu to validate your command:

"I am adding just one item to the order" - We have two questions: Does Restaurant/RestaurantMenu exist? Is that item on the Menu?
In this case, you only need to check events from the Restaurant/RestaurantMenu stream that are related to the concrete menu item. So, to introduce some kind of filtering on fetchEvents(command: C) per command. Most probably you need to model the state with the Union now, to cover all the variants. This is dynamic! It can be more performant. However, it introduces complexity and requires flexibility of the selected EventStore infrastructure that might not support additional filters of the decider/aggregate stream.

This question is interesting because it opens a new discussion on "Dynamic Consistency Boundry"

For example, Two "I am adding just one item to the order" commands should execute concurrently and in parallel, not sequentially. We are also changing the optimistic locking mechanism dynamically, on the storing new events side.

I would split them, and use Saga for now.