Um Repositroy (i.e. a interface exposta pelo que implementa o Repository) não deveria saber sobre transações, isso não faz parte do modelo. Mantêr transações sendo gerenciadas pelo DAO causa uma confusão bem grande com transações reentrantes. O livro Domain-Driven Design fala porque você não deve manter transações sendo gerenciadas pelo repositório -ou sua implementação- e porque você deve deixar transações serem gerenciadas pelo cliente do repositório.
Em geral, o cliente é que conhece o caso de uso e é quem sabe quando algo está completo ou não, o repositório, entities e etc são apenas partes de um processo maior e não sabem qundo é hora de fazer commit.
O controle transacional via Spring, ou ambiente JEE, ou com AOP, ou mesmo por um filtro podem ser considerados como UnitOfWork, certo? Ou seja, podemos considerar as demarcações como nossa UnitOfWork, correto? O que é bem mais simples e prático que fazer o controle manual através de um objeto como apresentado nos códigos acima.
Não. Não podem. UnitOfWork tem caracteristicas que esses outros não têm
é um controle explicito na forma de objeto
serve para controlar unidades de trabalho isso inclui transação mas tb concorrência. Esse concorrência
é feita em modo objeto ou seja, não tem a haver com o contexto transacional, ou melhor, é uma extensão dele.
UnitOfWork é o controle explicito de concorrência durante a escrita para um banco
Pela propria def do Fowler “Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.”
Os dados são afetados pela transação, mas a responsabilidade do objeto é controlar a concorrencia.
A transação continua ortogonal, mas a concorrencia não.