title: In DDD, a UoW per Repository or Bounded Context or Transaction?
body: <p>In DDD, an aggregate root can have a repository. Let us take an <strong>Order</strong> aggregate and it's non-persistant counterpart <strong>OrderRepository</strong> and persistent counterpart <strong>OrderUoW</strong>. We have also <strong>ProductVariant</strong> aggregate which tracks the inventory of the products in the order. It can have a <strong>ProductVariantRepository</strong> and <strong>ProductVariantUoW</strong>.</p>
  
  <p>The way the Order and the ProductVariant work is that before the order is persisted, the inventory is checked. If there is inventory, the order will be persisted by calling OrderUoW.Commit(). Yes, the ProductVariantUoW.Commit() will be called next to update the inventory of the products. </p>
  
  <p>UNFORTUNATELY things can go bad, a user bought the same products in that short time (Consider this as a web app where two users are buying the same products). Now the whole transaction for the second user should fail by reverting the order that just created. Should I call the OrderUoW to rollback the changes (the order should be deleted from the db)? Or should I put both UoW.Commit() operations in a transaction scope, so failing of one commit() will rollback the changes? Or both the repositories (Order, ProductVariant) should have only UoW and it needs to have only one transaction scope?</p>
  
  <p>I may be able to make the story short by saying, how the transaction is handled where there are multiple repositories involved?</p>