pcalcado wrote:

carol_programadora wrote:
Nos no meu "UserRepository" eu tenho algo mais relacionado ao negócio, suponhamos que eu precise de encontrar "Todos usuários com salário > 5.000, que tenham Casa própria quitada, que não tenha filhos, seja solteiro etc etc"(considere que seja uma consulta bem complexa) e lá na interface repository eu terei este método "findUsersBemDeVida();

Até ai ok, pois representa algo bem espefíco, mas agora se eu estiver usando este modelo:

UsuarioRepository > UsuarioDecorator(implements UsuarioRepository) > UsuarioDao

Não entendi, por que você está usando essa hierarquia toda? Que tal uma interface RepositorioUsuarios que é implementada por um UsuárioDAO, uma coisa simples que funciona?

carol_programadora wrote:
Onde ficará meu SQL(HQL seja o que for) dessa consulta?

Na implementação do Repositório, o DAO na minha proposta acima.

A.L wrote:
Corrija se eu estiver errado, mas no projeto exemplo do site oficial (dddsample) , existe um exemplo dessa situaçao, onde a interface do repositorio fica na camada de domínio, e a implementação, no caso em Hibernate, fica na camada de infra-estrutura/persistencia.

carol_programadora wrote:
Se nas minhas classes de controller, quando eu preciso de alguma consulta direta, sem ter negócio envolvido, inclua aqui dados brutos para popular comboBox, DataTable... etc eu tinha pensando em injetar uma dependência "UsuarioDao" no meu "UsuarioController" e não um UsuarioRepository... achei que fosse errado colocar uma dependência do repository no controller, achei que elas deveriam ser usada APENAS por classes do domínio, por domínio quero dizer as entities e os services, então eu pensei que o controller não deveria ter esse contato.
Então creio que estou errada, utilizando sua sugestão Shoes, minha única opção pra inserir dentro do "UsuarioController" seria minha "UsuarioRepository.

carol_programadora wrote:
Dentro de Application e Domain, tem pacote "service", pelo que li e entendi até agora(a não ser que fiz bagunça) minhas regras de negócio devem ficar no Domain > Service, certo?!

carol_programadora wrote:
Fiquei confusa com essa camada "Application", não tinha visto sobre ela no DDD, e na verdade pouco conheço ainda dela no geral

DDD, Capítulo IV wrote:
* User Interface (or Presentation Layer): Responsible for showing information to the user and interpreting the user's commands. The external actor might sometimes be another computer system rather than a human user.

* Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

* Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

* Infrastructure Layer: Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.