Event Proxy - Design Pattern

 

Explicitly express outside change as an event in your domain model, regardless of how it's delivered to your system; make delivery mechanism an implementation detail.

 

When an outside event is the reason of an action within the system at hand, it's important not to be distracted with the specifics of the event delivery between the systems. If domain experts mention specific condition as an event, we should express it as an event in our domain model too. However, often outside systems don't support push notifications to send to our systems, so the notion of the event can get lost into the paradigm of data polling or other interaction styles. This deviation from the original event concept creates problems long run, such as:

 

Event Proxy is the extension of the Proxy design pattern, with the event defined on it. In some cases, actual outside system may not offer such an event at all. That fact is hidden from the Event Listener since it's only dealing with the Event Proxy, and thus subscribing to the event exposed by the Event Proxy. Event Proxy in turn decides when to fire the event depending on the implementation of the outside system. If a push style event notification is available, then Event Proxy simply subscribes to the event of the outside system, and then fires its own internal event to the Event Listener in an answer to the outside event. If the outside system does not support a push style event notification, then Event Proxy may resort to other primitive mechanisms, such as polling the data every now and then, until the condition is met. Once the condition turns positive, Event Proxy fires the event to the Event Listener.

Implementation of the actual event delivery from outside system to the Event Proxy becomes irrelevant to the implementation of the Event Listener. By adding an interface of the Event Proxy to our domain model, alongside with the Event Listener, we explicitly express our intention to react to the outside event, regardless of how it's been delivered between the systems.

 

I have several other articles about design patterns like the one above. Also, I provide training courses for groups around various software architecture topics including several courses for design patterns.

 

About Author and Content

The author of the above content is Tengiz Tutisani.

If you agree with the provided thoughts and want to learn more, here are a couple of suggestions:

Ready to take the next step?

Let's Talk