A respeito do repositório PedidosFaturados, lhe pergunto, qual a sua agregação neste caso, sim porque o Evans deixa claro que os repositórios devem ser descritos para uma agregação, Perceba que pedidos faturados é uma característica do pedido, o conceito de negócio é o pedido e provavelmente deve ser a sua raiz de agregação. Imagine em um sistema grande, criar repositórios para cada carecterística forte de um conceito, imagine, por exemplo, no domínio de negócio recursos humanos, os seguintes “repositórios” funcionários em férias, funcionários em aviso prévio, funcionários em licença maternidade, etc. A raiz da agregação é o funcionário!

Outra coisa, sei que a interface do repositório faz parte do domínio, mas existe algumas dúvidas em relação ao seu uso diretamente nas Entidades. Perceba que os métodos do repositório podem receber como parâmetros objetos de negócio do domínio, então em uma entidade talvez não seja natural acessar tais métodos, já que isto levaria a um acoplamento da entidade a conceitos não naturalmente acoplados a ela.

Em relação a implementação de regras de negócio na classe que implementa a interface do repositório sou contra. Evans deixa claro que o papel dos repositórios e a reconstituição ou simples contagem de objetos. No seu exemplo, IMHO, estas regras deveriam ser escritas em um serviço (logicamente com o auxílo do repositório) ou até mesmo em uma entidade que acesse o repositório. Em seu exemplo, o cumprimento das regras de negócio envolvidas na operação “obter produtos disponíveis na data de entrega” vai além das responsabilidades de um repositório.

Isso mesmo! O termo PedidosFaturados era tão recorrente e tinha tanta coisa que acontecia com eles especificamente que valeu a pena criar um elemento com semântica própria.

@Otávio
Os services na maioria das vezes orquestram algumas tarefas que não são naturalmente alocáveis a nenhuma entidade. O melhor exemplo é o faturamento. Para faturar é necessário mudar o status do pedido, emitir uma nota fiscal, analisar crédito do cliente, gerar duplicatas e etc… Como o próprio Evans diz, certos elementos não são coisas, são processos. Validações da entidade estão na própria entidade. Sobre Layering (camadas) a discussão é grande, mas é comum aparecer esse padrão que você falou, a tela associada a uma facade de aplicação e a facade lidando com o domínio. Nada impede que um elemento de domínio vaze para a tela.

Abraço

Hamon, uso Specifications mais para “buscas que podem receber vários parâmetros opcionais”, como uma tela de busca e coisas do tipo. Usar specification para termos firmes da linguagem do domínio fica pouco ubiquitous. Entendeu? Note também que neste caso em específico “PedidosFaturados” só foi criado pois era um termo recorrente na linguagem. Para esse caso fez sentido criar um elemento com semântica própria.

Abraços

Mesmo com AOP ou Hibernate interceptores ainda falta uma perna com relação a injeção de Repositories. Quando eu dou apenas um “new” em meu POJO, como os repositories seriam injetados automaticamente? Via AOP é possível?

Abraço