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 principles, specifically bounded contexts, to draw the service boundaries. it's proving trickier than expected to define where one bounded context ends and another begins. for instance, is 'User' a separate bounded context from 'Identity' or 'Account'? should 'Order' and 'Payment' be completely distinct services, or is there an argument for keeping some shared context initially? we often find ourselves in disagreements about these boundaries, and it feels like there's no single 'right' answer. how do you typically resolve these ambiguities in practice? are there heuristics or questions you ask to help define crisp boundaries between services based on DDD principles?