Software systems seem to be ruled by a fundamental law: As they get larger, their complexity increases exponentially. The reason for this is actually simple: Complexity is due not just to the number of parts in the system, but also to the relationship between the parts. Event-Based Architectures (EBAs) simplify system design, development, and testing because they minimize the relationships between the parts of a system.
I've built a number of EBA-based systems, ranging from a Windows desktop app for the real-estate market with about 10,000 concurrent users, to a single-user desktop application that talks to a secure web service.
What Is an EBA?
An EBA is an architecture based on parts that interact solely or predominantly using event notifications, instead of direct method calls. An "event notification" is a signal that carries information about an event that was detected by the sender. While you're probably familiar with events like button clicks, events can be defined to include almost any conditions or occurrences you can think of. Notifications can be used to carry any domain-specific information you want, and in any type of systemembedded, GUI-based, distributed, or other.
There are different ways to deliver notifications, but the most common technique uses an indirect method call that is made through a pointer initialized at runtime. At design time, the compiler is unaware of what object (and perhaps even what type of object) the pointer will be referencing when the call is made. In an EBA, each part emits signals related to its internal state and reacts to signals received from other parts. This simple input/output model has important consequences: Each part can be developed and tested in isolation from the rest of the system, because it knows nothing about the other parts. In a well-designed EBA, the relationship of complexity versus size tends to be more linear than exponential, so the larger the system is, the better off you are with an EBA, compared to other conventional approaches.
Events and Notifications
Most popular object-oriented languages support the concept of events, but there is confusion between the terms "event" and "notification." Just to be clear, an event is something that happens to a part. As a result of the occurrence of an event, a part might emit a notification. Notifications are signals sent to other parts to inform them about an event. Events don't move around in a system, notifications do. As if there wasn't enough confusion between events and notifications, people often say "firing an event" to indicate the sending of a notification. The expression is so common that I use it throughout this article.