Does separating Domain model and Persistence model have impact on transactional aspect?

Question

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?

Answer 1

The linked blog post is rather vague and seems be a confusion of active record and entity object pattens rather than using data transfer objects.

Bear in mind that underneath whatever orm or wrappers you use you will be using a data transfer object such as a recordset to read and write the data.

So adding an extra one to abstract your data layer from your domain object doesn't fundamentally change what you are doing or prevent you implementing domain events when you persist the domain object.

Although that's completely different from "domain events" so another point of confusion.