I'm trying to wrap my head around event sourced architectures.
Note that what you are describing here is an event driven architecture. Event sourced really means something different.
If we talking about a microservice architecture, then we are expecting to be able to redeploy one microservice at a time. Autonomous microservices need to be capable of making progress even when a neighbor is being redeployed. Which produces a problem - my service can't make progress if it is waiting on an answer from your service, and your service is re-deploying.
The usual answer is to work with copies of data -- my service can make progress because it cached a copy of the information that it needs from you. In other words, if we agree to exchange messages asynchronously, rather than synchronously, then we don't get cascading outages when one microservice is unavailable.
Events are "just" messages; you need to have some way to exchange messages between the microservices in your system. You choose the appropriate transport for the circumstances you face. For example, Atom Syndication / Atom Pub gives you a nice standard for adding messages to a collection that is well understood by many organizations; but you may not want those sorts of trade-offs when you are dealing with a closed collection of microservices owned by the same company and running in close proximity to one another. An alternative is to use a message bus. Or to have your microservices share a common message store.
However, it doesn't seem possible to me to have small events AND no direct communication between services. e.g. An order service might need to know the name of a product which is stored in the product service.
To some extent it comes from separation of responsibilities -- why does the order service need anything more than an opaque product id? and is that coupling an indication that there is a design flaw somewhere else?
Many of the data designs of yesteryear were tightly constrained on space; we wanted to have a single copy of each fact to save space. The trades we make today are different, and with storage cheap it isn't as important to have a single copy of data (we still do need to be thinking about which data are copies and which are authoritative).
So yes, if the order service must have the product name, then there must be a message somewhere that brings that information. And therefore that message will need some transport to get where it needs going.
See also Pat Helland: Data on the Outside...