In virtually all of the video recordings Greg Young's presentations and PowerPoint slides, he talks about an event pipeline that comes out of the repository when events are committed.
One small optimization that helps with performance as well as availability of the system is to put the action of writing to your persistence engine as a subscriber on the pipeline rather than attempting to write to the persistence engine when committing the transaction. This is one of the main concepts behind a write-ahead log.
The reason that it helps with making the application more available is that your database doesn't technically have to be online in order for the application to continue processing events and committing them as transactions. We simply add committed events to the pipeline and all subscribers of those events are able to process them as they need.
Then, we create a special, multi-threaded subscriber to the pipeline. This subscriber transitionally reads the message(s) and updates the database accordingly and commits the transaction.
Another reason this helps with availability is because you have one less system involved in the transaction when your events are committed to the pipeline. How many times in a high-demand system has your thread been chosen as the deadlock victim? By making the persistence engine a subscriber on the pipeline, there are only two systems involved in a transaction at the end of a unit of work: the bounded context and the messaging system. Technically there's only one because the messaging channel is the only one with a transaction manager.
From a performance standpoint, the act of committing the unit of work in the bounded context is much faster because the transaction only needs to be committed against the messaging system. Once committed, the messaging system notifies all interested subscribers as quickly as possible. If a database was involved, then it would become a fully distributed transaction, which is much more expensive and much less "performant" than a local "simple" transaction against a single resource.