La separazione del modello di dominio e del modello di persistenza ha un impatto sull'aspetto transazionale?

1

In questo post , c'è:

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.

Non capisco perché il fatto di generare un modello di persistenza separato dal modello di dominio abbia un impatto sugli aspetti transazionali.

In effetti, finché un servizio di wrapping (use case) è responsabile per l'avvio e la chiusura (forse implicitamente) della transazione, il fatto che ci sia un modello di persistenza indiretto al modello di persistenza (dovuto alla mappatura da DM a PM) non dovrebbe avere influenza sull'aspetto transazionale, in particolare per quanto riguarda invio di eventi di dominio .

Ha a che fare con il fatto che l'oggetto da persistere sarà oggetto distaccato (poiché mappato da DM a PM) anziché tracciato?

Come capire questo frammento?

    
posta Mik378 09.07.2017 - 01:49
fonte

1 risposta

2

Il post del blog collegato è piuttosto vago e sembra essere una confusione di record di oggetti attivi e oggetti entità piuttosto che utilizzare oggetti di trasferimento dati.

Tieni presente che al di sotto di qualsiasi orm o wrapper che utilizzerai, utilizzerai un oggetto di trasferimento dati come un recordset per leggere e scrivere i dati.

Quindi aggiungere uno extra per astrarre il livello dati dal tuo oggetto dominio non cambia in modo sostanziale ciò che stai facendo o ti impedisce di implementare eventi di dominio quando persisti l'oggetto dominio.

Anche se è completamente diverso da "eventi di dominio", quindi un altro punto di confusione.

    
risposta data 09.07.2017 - 16:23
fonte