Domain-Driven Design in microservices: where do you draw bounded context boundaries?

We're in the process of decomposing a large monolith into microservices, and we're trying to use Domain-Driven Design (DDD) to define our bounded contexts. While the theory sounds good, in practice, drawing these boundaries can be really ambiguous and lead to a lot of debate among architects and teams. For example, where do you draw the line between a 'User' bounded context and an 'Identity' bounded context? Or for an e-commerce platform, what's the distinct boundary between 'Order Management' and 'Payment Processing'? They're clearly related but also have distinct responsibilities. We often find ourselves with shared concepts or data that make it hard to create truly independent contexts without a lot of duplication or complex synchronization. How do experienced teams resolve these ambiguities and disagreements when defining bounded contexts? Are there heuristics or common patterns for splitting responsibilities that you've found effective? It feels like the most critical decision, as getting it wrong can lead to distributed monoliths later on.