Hi Steven,
this is valuable information, although I am not sure what we can do with it. By design, the components dealing with different Saga types are separated. So ideally, I would like them to be split.
However, a potential performance optimization is something that we shouldn’t ignore either.
One thing that I could think of, is to have the SagaStore always query for all Saga types matching a specific association and attach that information as a Resource with the Unit of Work. When the next component queries, it can see the information in the Unit of Work and use that, instead of doing another query.
This would only be an optimization if multiple Sagas need to be invoked for the same Event Message and in the span of the same (root) Unit of Work. Having 2 Tracking Processors, for example, would not allow for this optimization to be effective.
Adding a “real” cache is something I won’t be too comfortable with, as associations can change during the lifecycle of a Saga. The chance of such a cache to become stale (and incorrect) is too big.
Cheers,
Allard