In this post, there is:
For example, with your own persistence model, you are not able to benefit from the built-in change tracking functionality. And that means you will not be able to implement reliable domain events – the ones which get fired only when a transaction gets committed to the database. You either need to build a change tracker yourself or give up on such implementation of domain events.
I don't figure out why the fact to spawn a persistence model separated from domain model would impact transactional aspects.
Indeed, as long as a wrapping service (use case) is responsible for starting and closing (maybe implicitly) the transaction, the fact that there is one indirection to persistence model (due to DM to PM mapping) or not should not have influence on transactional aspect, especially regarding domain events dispatching.
Does it have to do with the fact that the object to persist will be detached object (since mapped from DM to PM) rather than tracked?
How to understand this snippet?