Event-based systems are systems in which the constituent modules (or components) have no direct connection to each other. I agree that this statement by itself is quite vague. So, let's explore it further using a typical service-oriented, N-tiered Web application.
An end user submits an order form using a Web browser, which results in a boundary service on the server side being invoked. This boundary service then finds and invokes the appropriate business components, which in turn may invoke a series of other business and data components, and so on. Each component in this system, including those on the client side, knows exactly which component (or set of components) it needs to invoke next, and furthermore, this logic is built into the application itself rather rigidly. Changing this logic in most cases entails a developer making a change to the application code.
The reason for this is simple: components in such a system are directly connected (or coupled) to each other. There are two generally accepted ways of establishing this connection between the two components. The more common approach is through the use of a factory pattern. The "caller" component uses the factory to locate or obtain a reference to the "callee" component. The other way, which is a more recent development, uses a pattern called "dependency injection," in which the "caller" component provides a way for the container to inject (i.e. provide) a reference to the "callee" component during startup (or whenever the "caller" component is created/initialized).
(There is actually a third way to establish the connection. The "caller" component could simply create the "callee" component itself. This is the least desirable way of the three and should be avoided in all except the simplest of systems.)
Now you know.