Return to Answer

PlaceBidHandler (moves money into escrow):

// throws NotFound
account = accounts.Find( cmd.UserId ) 

// throws InsuficientFunds or raises `BidPlaced`
account.PlaceBid( cmd.AuctionId, cmd.LotNumber, cmd.Amount ) 

SubmitBidHandler (keeps track of all Bids or maybe just highest Bid):

The Auction (which mediates the process) is simply responsible for reacting to BidPlaced events in a way to trigger SubmitBid OR RevokeBid commands (should NotFound be thrown), and reacting to Outbidded events in a way to trigger RevokeBid commands.

If you would like to keep Account and Auction in separate contexts (you don't want Account.PlaceBid), this can be modified further to add an extra layer along the lines of: PlaceOrder -> PaymentReceived -> PlaceBid (in this case ordering a Bid and debiting account) and BidRevoked -> RefundPayment to cleanly separate accounts from auctions.

OfferBidHandler (moves money into escrow, creates Bid):

// throws NotFound
account = accounts.Find( cmd.UserId ) 

// throws InsuficientFunds or raises `BidOffered`
account.OfferBid( cmd.AuctionId, cmd.LotNumber, cmd.Amount ) 

PlaceBidHandler (keeps track of all Bids or maybe just highest Bid):

The Auction (which mediates the process) is simply responsible for reacting to BidOffered events in a way to trigger PlaceBid OR RevokeBid commands (should NotFound be thrown), and reacting to Outbidded events in a way to trigger RevokeBid commands.

If you would like to keep Account and Auction in separate contexts (you don't want Account.OfferBid), this can be modified further to add an extra layer along the lines of: PlaceOrder -> PaymentReceived -> PlaceBid (in this case ordering a Bid and debiting account) and BidRevoked -> RefundPayment to cleanly separate accounts from auctions.

PlaceBidHandler (moves money into escrow):

SubmitBidHandler (keeps track of all Bids or maybe just highest Bid):

RevokeBidHandler (removes money from escrow):

PlaceBidHandler (moves money into escrow):

SubmitBidHandler (keeps track of all Bids or maybe just highest Bid):

RevokeBidHandler (removes money from escrow):

DDD is a design process that understands real-world problems can sometimes reach a level of complexity that they cannot be cleanly separated and modeled into completely independent units. That is, process itself can have rules and when such a situation arises, eventual consistency can be employed to offer a solution. I don't read the quote you offer from the blue book (in the OP comments) as advocating for any mode of consistency, rather pointing out that it is often a desirable and sometimes necessary attribute within a system of which we need to be aware when forming our expectations.

Whether or not a given system needs to employ an eventual consistent paradigm should be determined through analysis of its requirements in terms of scaling, not through analysis of it's design (though the former can certainly inform the latter). This decision should not be made lightly (and doesn't have to be all-or-nothing), because the trade-offs are steep and often requires much greater complexity in terms of implementation where employed.

If you would like to keep Account and Auction in separate contexts (you don't want Account.PlaceBid), this can be modified further to add an extra layer along the lines of: PlaceOrder -> PaymentReceived (in this case ordering a Bid and debiting account) and BidRevoked -> RefundPayment to cleanly separate accounts from auctions.

DDD is a design process that understands real-world problems can sometimes reach a level of complexity that they cannot be cleanly separated and modeled into completely independent units. That is, process itself can have rules and when such a situation arises, eventual consistency can be employed to offer a solution. I don't read the quote you offer from the blue book (in the OP comments) as advocating for any mode of consistency, rather pointing out that eventual consistency is often a desirable and sometimes necessary attribute within a system of which we need to be aware when forming our expectations.

Whether or not a given system needs to employ an eventual consistent paradigm should be determined through analysis of its requirements in terms of scaling, not through analysis of it's design (though the former can certainly inform the latter). This decision should not be made lightly (and doesn't have to be all-or-nothing), because the trade-offs are steep and often require much greater complexity in terms of implementation where employed.

If you would like to keep Account and Auction in separate contexts (you don't want Account.PlaceBid), this can be modified further to add an extra layer along the lines of: PlaceOrder -> PaymentReceived -> PlaceBid (in this case ordering a Bid and debiting account) and BidRevoked -> RefundPayment to cleanly separate accounts from auctions.