The problem is covered in Chapter 5. There's isn't really a silver bullet, depends a bit on your use case. He outlines a couple of approaches:
* Try Again Later: queue failed parts of the transaction for retry, moving towards eventual consistency
* Abort the Entire Operation: On failure issue a compensating transaction to roll back the previous successes
* Distributed Transaction: have some overall governing transaction manager process that orchestrates consistency (e.g. duplicate the transaction process of your monlithic data store up in the application layer). You could do a two-phase commit where each participant in the distributed transaction tells the transaction manager whether it thinks its local transaction can go ahead. "A single no vote is enough for the transaction manager to send out a rollback to all parties."
For each of these approaches there are issues, obviously, and to his credit he's pretty even-handed about them. He also says:
"If you do encounter state that really, really wants to be kept consistent, do everything you can to avoid splitting it up in the first place. Try really hard. If you really need to go ahead with the split, think about moving from a purely technical view of the process (e.g., a database transaction) and actually create a concrete concept to represent the transaction itself."
He gives an example of a domain model for a retail company of an order-in-process: instead of attempting to capture a user's order as a single database transaction, model the concept of an order flow of through fulfillment, shipping, marketing, accounting, etc.