title: Multiple repositories under the same transaction
body: <p>Imagine a situation when the application layer opens a new transaction and you want to perform 2 repository operations under this transaction. Let's say I want to add a new User with IUserRepository and afterwards save all events that were generated during User domain model state change. I open a new transaction in ApplicationLayer (TransactionScope), then perform these 2 operations. But what if tommorow I want to change the repository implementation to FileBasedRepository or HttpCloudRepository. Repositories don't know about the fact that they are running under some transaction, or should they?
  The main question is about abstractions. We all strive to write code based on abstractions. What I see is if I implemented a unit of work and I update 2 aggregates using 2 repositories in application layer(repositories work with MSSql), tommorow I can't change one of the repositories implementations to httpbased or in memory based. The question is about how to write such code. Seems like I have to create an abstraction over transaction and implement rollbacks by my own for HttpUnitOfWork. Feels like my initial unit of work is tightly coupled to db and shoould be renamed DbUnitOfWork. But that's wrong again, cause there are no sql databased which don't support transactions at all. </p>