Engraçado é que no seu próprio exemplo tinha um simples cadastrinho que não ia dar em nada. Acontece que seu cliente pediu para realizar a tarefaX antes de gravar os dados e eis que surge uma regra de negócio no repositorio.
Estamos repetindo as mesmas coisas várias vezes de forma diferente. Não está mais valendo apena. Desculpe qualquer coisa e abraços. 
[quote=emerleite]Engraçado é que no seu próprio exemplo tinha um simples cadastrinho que não ia dar em nada. Acontece que seu cliente pediu para realizar a tarefaX antes de gravar os dados e eis que surge uma regra de negócio no repositorio.
Estamos repetindo as mesmas coisas várias vezes de forma diferente. Não está mais valendo apena. Desculpe qualquer coisa e abraços. [/quote]
… e como já disse várias vezes, eu poderia em vez de colocar a regra no repositório, colocar em um Service (como já postei aqui)… a escolha de colocar no repositório foi minha (era só fazer a chamada ao service no lugar do repository). Outra coisa é o debate sobre utilizar recursos do framework para persistência transparente e isso de nada tem haver com o exemplo citado.
Sim, estamos repetindo.
Abraços
[quote=Lezinho]Shoes, seu formulário lida com objetos de modelo na camada de apresentação, ele recebe e exibe dados por essa camada. Ao receber os dados pelo formulário e este ser submetido, o próprio binding dos campos atualiza o estado de seu objeto em qualquer ferramenta MVC. A camada de negócio já recebe este objeto em novo estado atualizado, é sobre isso que postei.[…]
A persistencia nas RAds é tratada sobre um componente pouco reutilizável que muitas vezes é colocado escancarado sobre a própria UI. Ja nas páginas não existe componente associado, uma EL que pode ser qualquer coisa que faz as invocações.[/quote]
Eu tenho a impressão que estamos nos repetindo. Possivelmente não concordamos e ponto.
Para clarificar, existem dois problemas sendo lidados nesta thread:
Camada de Apresentação acessando diretamente Repositorio: Apesar de não ferir Camadas isso faz co que elas perdam bastante de seu sentido. Sua UI deveria conhecer sobre a lista de itens retornada pelo repositorio, nao pelo repositorio em si. Existem diversos problemas decorrentes disso e para mim você já está vivendo um deles quando tem que colocar regras de negócio no repositório simplesmente para que elas façam parte do fluo, já que você não tem um orquestrador de fluxo que seria a Camada de Aplicação.
Camadas: Para justificar o problema acima você colou um diagrama onde superiores acessam as ultimas Camadas. Eu afirmei que isso nao é um problema mas que no ontexto de DDD é usado no livro apenas como introdução à Camadas, e que se isso fosse para ser seguido à risca você teria interface -> DAO (ou mesmo interface -> JDBC) como algo completamente aceitável. Você falou que dpeendendo da infra-estrutura isso era OK. O que eu fiquei repetindo nos posts subsequentes é que isso Não é aceitável para um Domain Model sadio -pensando em melhor design possível, não em design incremental, YAGNI ou pragmatismo.