It seems to me like the entirety of a program's logic can be incorporated in process managers and aggregates of a CQRS/ES system. On the other end of the spectrum, it seems like you can also decide to only emit commands to change a database, which otherwise you're reading from for your logic as usual, with a majority of program state not in aggregates or process managers.
Remember this is all domain-driven design. You "should" have aggregates already, they are just collections of domain objects. The event sourcing part comes from issuing commands to your aggregates, and them emitting events. Commands should be commands to your aggregates. If you find yourself sending commands that pass completely through your aggregates without affecting state, you might be on the wrong track.
But those commands were caused by some real-world event. Where did that event come from? Can you model the source as an aggregate? Should you?
A problem I'm running into that I'm trying to get around is the inability to directly issue events, and instead having to issue commands based on these events. I'm implementing a network protocol, and I receive packets from the outside. What command do I issue in response to that packet? I'd rather issue that received packet as an event, and have my process managers figure out how to handle it. The result of this is commands that don't affect my aggregates that only exist to pass data through to the process manager, like "handle packet" emitting an event "packet received".