[quote=sergiotaborda]O limite da transação é o serviço. É por isso que serviços não são repositorios e vice-versa. Para que haja modificação do estado do sistema o fluxo deve passar por um serviço.
A camada de serviços não é uma moda, é uma necessidade. [/quote]Ótimas colocações!! :thumbup:
[quote=sergiotaborda]Mas existem dois tipos de serviços. O de aplicação e o de dominio.
O de dominio é transacional e provoca uma alteração no estado do sistema ou implica numa regra do dominio. O de aplicação dá suporte a serviços não-funcionais como mandar emais. Estes serviços podem ser transacionais e são chamados de serviços de dominio. Estes são serviços de suporte que podem ser usados por várias aplicações diferentes.[/quote]Estes “serviços de suporte”: não me agrada nada chamá-los de “Serviços de aplicação”. 
(Sei, sou suspeito p/ falar, pois sou 1 grande fã do DDD! =P) Prefiro colocá-los num Pacote ‘InfraServices’ e chamá-lo de ‘utilInfraSrvc’, p/ex., ‘mensagemInfraSrvc’: para envio - usando o DIP - é transparente para o Domain se a Msg é enviada via E-Mail, ou de outra forma. (Só ficou confusa esta parte: “O de aplicação dá suporte a serviços não-funcionais como mandar emais. Estes serviços podem ser transacionais e são chamados de serviços de dominio.”.)
[quote=sergiotaborda]O senhor Evans não é a melhor referencia para nomenclatura. É dele a autoria da asneira de confundir Repositorio e DAO porque não teve o mesmo cuidado que o Fowler teve quando redefiniu o termo “value object”. O repositorio-DDD pode ser um DAO, uma lista, um qualquer coisa que se assemelhe a uma coleção.[/quote]Não consta, pelo menos no resumo do InfoQ, nada sobre o “Repository ser um DAO”. Mas, volto a citar: “A Repository may contain detailed information used to access the infrastructure, but its interface should be simple.” e “… the implementation of a repository can be closely liked to the infrastructure, but that the repository interface will be [color=red]pure[/color] domain model.” Então vemos que foram usando os verbos “may” e “can” (ou seja, “pode”) e não foi usado ‘must’ (‘deve’/deveria). Ou seja, ficou claro ele q denota 'Repository’s como um tipo de Arquivo Lógico.
Vejo a coisa da seguinte forma (e até o pessoal do princípio KISS e/ou agilistas vão concordar): os Repository’s podem ter um atributo ‘EntityManager’ (do JPA, o qual inclusive alega abstrair/encapsular a DAO) injetado por um @PersistenceContex; caso sejam percebidos “gargalos” em alguns Objetos DomainModel, seu Repository poderia então usar uma DAO, c/ abordagem JDBC puro p/ex., sendo esta DAO implementada num Pacote (totalmente) fora do Domain.
[quote=sergiotaborda] O Repositorio ( padrão Repository) inventado pelo fowler não pode ser um DAO, nem Lista, etc… e isso é explicito no padrão. O ponto é : não confie muito na nomenclatura definida pelo Evans e muito menos a generalize.
[/quote]Bem, isto já um questão intrerpretativa sua. Na obra de Evans, as únicas coisas q eu não gostei foram: 1. A ambiguidade, sobre Aplicação, entre o termos “software application” (Aplicação de Software, como um todo) e “application layer” (q, na minha interpretação, entendo como o FrontController); e 2. um equívoco conceitual, muito além de uma nomeclatura ambígua, de definir um ‘Service’ nesta dita “application layer”. (O que é ainda pior.) :x
Mas, Q bom o Fowler ser mais assertivo/acurado. (É p/ isso q eu sou muito fã dele! 
)
(Ah, só uma Obs.: como o casal Freeman sempre fala: Os Padrões não são “inventados”, são “descobertos”!)
(Sei, sou suspeito p/ falar, pois sou 1 grande fã do DDD! =P) Prefiro colocá-los num Pacote ‘InfraServices’ e chamá-lo de ‘utilInfraSrvc’, p/ex., ‘mensagemInfraSrvc’: para envio - usando o DIP - é transparente para o Domain se a Msg é enviada via E-Mail, ou de outra forma. (Só ficou confusa esta parte: “O de aplicação dá suporte a serviços não-funcionais como mandar emais. Estes serviços podem ser transacionais e são chamados de serviços de dominio.”.)