Event Driven Architecture is about components communicating via publishing events rather than making (e.g.) RPC calls against each other or manipulating shared state. It's a communication strategy (albeit one which often relies on messages being persisted for fairly long periods).
Event Sourcing is when the components themselves treat the history of events which they have persisted as the ultimate source of truth for their state (or at least the state that they actually care about). It's a persistence strategy and doesn't intrinsically say anything about communication. Event Sourcing doesn't intrinsically have anything to do with CQRS (though event sourced systems do often find CQRS useful as a means of allowing queries which would have to replay a non-trivial subset of events to use a data model more optimized for that use case; likewise, there are some advantages to using an event sourcing persistence model for processing commands in a CQRS).
The persisted events being the ultimate source of truth implies that an event replay recovers the state (by definition, if an event replay could not recover the state, then the events were not the ultimate source of truth).
Event Sourcing is keeping a log for your own use so you don't forget. Event Driven Architecture is about communicating what happened to others. Typically, components in EDA can't recover the entirety of their state from the events they've published because not everything that changed their state is worth publishing. A component which only takes as input events published by other components is able to recover its state based on replaying those events (though in many cases replaying them in the same order as they were published is quite difficult...), though I'd argue that that is command sourcing, not event sourcing, because an event published by one component is a command when consumed by another component (the command being "try to incorporate this event into your view of the world").
The log of events in an Event Sourced component is a very good (I'd even suggest that it's the optimal) source for deriving events to publish in an Event Driven Architecture, so Event Sourced components can be a part of an Event Driven Architecture.
For example, consider a shopping cart service backed by a relational DB. The cart is represented in the DB by a row in a carts table and a cartitems table represents tracks has rows that say "2 USB chargers in cart ABC with price $4.75 apiece". To add items to the cart we insert (or update if it's just a quantity change) rows to the cartitems table. When the cart is checked out, we publish a JSON representation of the cart and its contents so the shipping service has what's in the cart and we set carts.checked_out to TRUE.
That's a perfectly OK Event Driven Architecture. The cart service communicates that there's a checked out cart to the shipping service. It's not event-sourced: we can't reconstruct the DB from the events.
The shopping cart service could be event sourced. It stores events in an event store (which could be a datastore designed for the needs of event sourcing or could be relational DB or non-relational DB being used in a particular way (e.g. an events table)). The following sequence of events for cart ABC might be written to the event store:
- AddItem { "USB charger", $4.95 }
- AddItem { "USB charger", $4.95 }
- AddItem { "Camel Book", $34.95 }
- RemoveItem { "Camel Book" }
- DiscountApplied { Requirement { 2, "USB charger" }, -$0.40 }
- AddItem { "The C Programming Language", $19.95 }
- CheckedOut { Items { Item { "USB Charger", 2, $4.75 }, Item { "The C Programming Language", 1, $19.95 } } }
That last event (along with the fact that it's for cart ABC, which is metadata associated with the event) can be used to derive an event for publishing. One key thing to note is that there's nothing else being written to the DB but these events.
As far as Event Driven Architecture is concerned, these two cart services are basically the same: they publish the same checkout events. That one is event sourced is really just an implementation detail of that service.
