Dúvidas sombre modelagem de dominio

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?

att
fidencio

sfidencio wrote: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?

att
fidencio

Bom, a primeira questão é bastante importante, separar o domínio das demais camadas da sua solução é primordial. Como está fazendo?

Senão me engano, o uso de DTO (aquele do J2EE patterns da Sun) não é bem visto, hora ou outra vai cair no conceito de modelo de domínio anêmico (tudo desmembrado, perdendo real sentido)

Colocar lógica de negócio numa entidade (por ex a Cliente) é apreciado, tem muito exemplo disso por ai (exemplos aprovados \o/). Apesar que cada caso é um caso, esses comportamentos devem estar em acordo com o que sua entidade desempenha no domínio.

Os CRUDs da vida dentro de uma entidade convergem para um ActiveRecord (corrijam se estiver errado), mas também está OK. Desde que a parte bruta, operações de infra, que extrapolam para sqls/xml/nao- tem-a-ver-com-domínio, estejam em outra camada.

Sobre Respositories, tem um post bem legal do Fabio Kung

http://blog.caelum.com.br/2007/06/09/repository-seu-modelo-mais-orientado-a-objeto/

E sobre o uso de DAOs, é um assunto que deu muito pano pra manga, então tem esse post do Philip Calçado muito bom também:

http://blog.fragmental.com.br/2007/06/05/dao-e-repository/

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

sfidencio wrote: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?

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.

sfidencio wrote:
1. não estou conseguindo praticar DDD, ou seja, focar no meu dominio.

Esse problema é muito sério. Se você não entender do que se trata o seu domínio nem precisa continuar lendo daqui pra frente. Não existe regra para essa definição isto deve partir do seu conhecimento sobre o negócio em questão.

sfidencio wrote:
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?

O Pattern DTO serve para transferir dados de uma camada a outra. Ele não tem nada a não ser um monte de atributos e get e set, se você possui a necessidade de ficar trafegando dados use-o. Na sua classe de liente ponha apenas os atributos e os métodos referentes a um cliente. CRUD fica no seu repositorio.

sfidencio wrote:
3. Não estou conseguindo entender o uso do repository...quem comunica com quem..quem chama quem..quem implementa quem?

A comunição dentro de um domínio não é unidirecional, uma classe pode falar com todas as outras do mesmo domínio, porém é bom que apenas o serviço fala com classes de outros domínios (apenas para ficar mais claro na sua arquitetura).

sfidencio wrote:
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?

O DAO é quem efetivamento traz os dados para a gente de alguma fonte que ele conhece, nesse caso o seu repositório teria um DAO via agregação. O seu repositório não pode ter uma Connection ou um EntityManager(recomendação), deixe isso no DAO assim se for preciso alterar a fonte de dados o seu repositório não sofre muitas alteralções.

Notícias, artigos e o maior fórum brasileiro sobre Java