The Repository API and thus Usecase layer are tightly coupled to gorm. Gorm is an infrastructure concern and must not be exposed to application services & the domain model. Instead we can expose a Tx interface which models a transaction and the operations which can be done within that unit of work.

There are two levels we could do these at:

1. An entire Store level, possibly encapsulating multiple repositories. This would allow transactions to span multiple repositories. This is usually a no-no, though, as an Aggregate is supposed to be the unit of work for decoupling and scale reasons. We may want to give ourselves room to bend the rules, but I don't think it should be warranted.
2. The Repository level. This is a bit more "by the book". This is shown below.

type ResourceRepository {
        Begin() Tx
}

type ResourceTx {
        NextResourceId() (bizmodel.ResourceId, error)
        NextReporterResourceId() (bizmodel.ReporterResourceId, error)
        Save(resource bizmodel.Resource, operationType biz.EventOperationType, txid string) error
        FindResourceByKeys(key bizmodel.ReporterResourceKey) (*bizmodel.Resource, error)
        FindCurrentAndPreviousVersionedRepresentations(key bizmodel.ReporterResourceKey, currentVersion *uint, operationType biz.EventOperationType) (*bizmodel.Representations, *bizmodel.Representations, error)
        FindLatestRepresentations(key bizmodel.ReporterResourceKey) (*bizmodel.Representations, error)
        HasTransactionIdBeenProcessed(transactionId string) (bool, error) // 
        Commit() error
        Rollback() error
}

Strongly consider whether RHCLOUD-45262 should be done with the same change or not. Include it if it is simpler to incorporate early. Otherwise, multistep is okay.