[quote=sfidencio]Estou modelando um sistema e estou com as seguintes duvidas:
1. não estou conseguindo praticar DDD, ou seja, focar no meu dominio.
2. Usando essa abordagem..posso continuar usar DTO. ou seja..classe de dados separado de negocio?. ou posso na minha classe Cliente por exemplo..colocar meus metodos de negocio+crud..e atributos privados?
3. Não estou conseguindo entender o uso do repository...quem comunica com quem..quem chama quem..quem implementa quem?
4. To implementando o padrao DAO with J2EE de acordo com site da sun. esse padrão envolve o pattern..strategy e factory..portanto não pretendo usar orm, e sim jdbc puro. Então o que me dizem?
[/quote]
O primeiro erro é achar que só existe CRUD num sistema. No minimo existe CRUDL onde o L significa List. Este L é que é o ponto e compoe a maior parte das features. Vc grava pedidos usando CRUD mas depois tem que os manipular em diversas situações, atualizar status, etc… isso implica listar os pedidos que obedecem certos critérios.
O segundo erro é seguir DDD. Esqueça isso até entender OO.
A camada de dominio não é uma coisa inventada pelo DDD. Nem o Repositorio, nem a Entidade.
O Dominio é composto por 4 principais objetos. Entidades, Repositorios, Serviços, Validadores
As entidades contém dados e regras sobre esses dados. Os validadores contém regras sobre quais dados fazem uma entidade ser aceitável.
Repositorios armazenam entidades e são responsáveis pelas pesquisas (listar). Serviços manipulam qualquer um dos outros 3, em qualquer numero e grau para obter uma funcionalidade não trivial.
“focar no dominio” significa: identifique data classe deste 4 tipos , mas lembre-se que nem todas as classes do sistema estão na camada de dominio.
Abaixo da camada de dominio está a camada de integração. Aqui vc integra o dominio com outros dominios ou sistemas. Na maioria dos casos vc quer integrar com um banco de dados. Usar o DAO com JDBC hoje em dia não é aconcelhável a novatos. Use o Hibernate. Para desacoplar o uso do hibernate do repositorio vc irá precisar de vários outros objetos, como estratégias, query Objects e Interpreters.
Acima da camada de dominio está a camada de apresentação. Ela tb contém regras especiais, nem todas ligadas ao dominio per se. Quando a apresentação precisa pesquisar algo, ela delega a um repositorio. Se a pesquisa é complexa, ela delega a um serviço, que por sua vez delega a mais do quem repositorio (padrão Façade). Quando a apresentação quer delegar alguma ação do usuário como aprovar um orçamento, salvar um cliente, etc. ela delega a um serviço. O serviço que altera o sistema sempre tem que validar os dados antes usando um Validador.Não é a action que valida, é o service. A action tem que interpretar a resposta do service ou as exceptions do service.
Entidades parecem DTO , então não ha nada de especial aqui. Na realidade entidades são objetos com get/set a diferença é uma entidades pode referenciar coleções de outros objetos e Entidades e é nisso que ela difere do DTO.
Não coloque mecanismos de persistencia na entidade. O padrão ActiveRecord não é desenhado para esse tipo de sistema em camadas. Nestes sistema ele é um anti-pattern.
Esqueça o DAO, isso é coisa do século passado (literalmente). E principalmente não confunda DAO com repositorio.