It is a Design Problem which I am listing out here.

I have multiple event sources in my app, each one produces events with the different set of data (but each source is producing only one type of event). On the other side, I've got multiple actions, that can be triggered by sources.

Sources and actions may be extended in future (There may be more of them).

Which action is triggered when is stated in a configuration that can be changed during runtime - in other words, user suppose to have opportunity to say, for example, "when source 1 will produce event, then fire action 2" or "when source 2 will produce event, then fire action 1 and action 2" etc.

What's more, events should be able to be filtered based on their settings, for example, the user can set "when source 1 will produce the event, then fire action 2 but only when the produced event contains date lower than today"

I've tried to draw something to maybe better illustrate my problem (and solution I was thinking of):

enter image description here

As it is written in the picture, I think that kind of mediator pattern should be used here.

But I have the following problems:

  1. I'm not sure if the mediator is a good place for filtering. I've marekd that configuration is injected here, but still not sure about it.

  2. Each of actions should be able to handle each of source - but since events are different, without the same ancestor, each action will have to be able to consume each event type. So when adding a new source, I will need to add handling method in each action. And I'm thinking if there is a way to avoid that.

1 Answer 1


What that you explain here is a classic Publish-subscribe question.

Regarding your questions:

  1. You can delegate the filtering task to an external entity, which your configuration updates care to inform. (it can be a filtering task per source/groups of sources/every source depending on your requirements).
    In order to do it, the filtering tasks need to synchronize with the configuration management entity and the event sources need to traverse their appropriate filtering task, before being able to "publish".

  2. I would suggest that if you can create a uniform representation for the events sent to your actions it'll be helpful.
    Either way, I would advise you to handle it in a centralized place and don't create a specific handler for-each data source for-each action type (which will create a N*M handlers [N = Event source, M = Action type]) and it'll be hardly maintainable.
    Strive to create an internal representation to translate to and from (and you'll have N+M handlers).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.