An event is the result of a command execution within an application. These are used as a notification mechanism for subscribers who are interested in receiving them. Events are immutable and should not be modified, as they are designed to keep a log that keeps information on how the application state has mutated over time. 

When it comes to naming events, the rule of thumb is to use past tense, such as the following: 

• Money transferred
• User information updated
• Account created

Events are not concerned with what actions will be performed after their creation. This makes it possible to decouple a system but still notify the subscribers. In this way, we can decouple applications because the subscribers are responsible for executing one or more operations, depending on what is needed when they have been notified of an event's creation.

At this point, we can conclude that we can decouple applications because the subscribers are responsible for executing one or more operations, depending on what is needed when they have been notified of an event's creation. We can also infer that events are an excellent way to reverse dependencies by delegating responsibilities to other systems. 

The following diagram shows how a command emits events and how the subscribers to these events are notified:

Now that we have a better understanding of events, let's review the four patterns that we mentioned at the beginning of this chapter in order to create applications using an event-driven architectural style.