Instanciação de Entity, classe de domínio, DDD Evans, onde é correto?

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Eu não vejo problema nenhum na camada de visão estar acoplada ao domain. Na verdade o problema é quando o domain está acoplado à camada de visão. Se você estiver usando um framework que faça o bind recusivo pra você, o framework já fará isso pra você quando receber os parametros. Um framework que faz isso é o Struts2. Ele tem uma interface que se chama ModelDriven e que permite que a Action seja tratada como um wrapper para uma classe de Domain. Algo assim:

Dessa forma quando sua action receber um parametro nomeado "nome" ela executará

suaAction.getModel().setNome(request.getParameter("nome"))

Mas isso é transparente pra você.

Abração

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Lezinho wrote:Camada de visão e aplicação não é domínio, portanto de nada tem haver com DDD. Pode usar EntityManager, Session, SQL direto na página via JSTL ... Eu quando tenho CRUD simples sem intervenção do negócio não escrevo uma linha de código java, utilizo o DAO declarativo do Seam.

Mas tudo isso, de nada tem haver com DDD ... [2]

Isso não acaba gerando regras de negócio fora do domain? Acho que o domain é reponsável por tratar e resolver todo o problema do sistema, e o CRUD está incluso como problema do sistema.

This message was edited 1 time. Last update was at 25/11/2007 14:31:33

feliperod wrote:

Lezinho wrote:Camada de visão e aplicação não é domínio, portanto de nada tem haver com DDD. Pode usar EntityManager, Session, SQL direto na página via JSTL ... Eu quando tenho CRUD simples sem intervenção do negócio não escrevo uma linha de código java, utilizo o DAO declarativo do Seam.

Mas tudo isso, de nada tem haver com DDD ... [2]

Isso não acaba gerando regras de negócio fora do domain? Acho que o domain é reponsável por tratar e resolver todo o problema do sistema, e o CRUD está incluso como problema do sistema.

Se vc preenche um formulário, clica no botão e os dados são persistidos e validados sem você precisar programar, não existe mal que isso fique em um framework (acredite, isso é possível com frameworks como o Jboss Seam). Não é preciso DDD para isso pois Domain Driven é para construir o Design do código, mas já que você não precisou codificar, portanto não precisou do design.

Se seu CRUD ficar mais complexo, então neste momento você constrói classes para isso com DDD... mas note que você não precisou disto no primeiro momento e pode ser que nao precise para o sistema inteiro. Programação incremental é uma ótima aliada a metodologias ágeis e não fere preceitos de design.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Lezinho wrote:
Se vc preenche um formulário, clica no botão e os dados são persistidos e validados sem você precisar programar, não existe mal que isso fique em um framework (acredite, isso é possível com frameworks como o Jboss Seam). Não é preciso DDD para isso pois Domain Driven é para construir o Design do código, mas já que você não precisou codificar, portanto não precisou do design.

Se seu CRUD ficar mais complexo, então neste momento você constrói classes para isso com DDD... mas note que você não precisou disto no primeiro momento e pode ser que nao precise para o sistema inteiro. Programação incremental é uma ótima aliada a metodologias ágeis e não fere preceitos de design.

Concordo com você em relação à aplicação ser simples o suficiente pra não usar DDD. Mas numa aplicação complexa, onde já estamos usando DDD, deixar o CRUD fora do domain não seria bobagem? O CRUD não acrescenta muito código ao domain.

E no caso de não utilizar o Seam? Mesmo caso. Você não terá um framework para isso.

Outra situação é se o domain é o mesmo para várias interfaces, então é bom que seu domain faça o trabalho todo do sistema, deixando só a persistência e a visão para ser trocada.

This message was edited 1 time. Last update was at 25/11/2007 16:26:10

Concordo com você em relação à aplicação ser simples o suficiente pra não usar DDD. Mas numa aplicação complexa, onde já estamos usando DDD, deixar o CRUD fora do domain não seria bobagem?

Mas eu não me referi a aplicações simples, nem para aplicações que não usam DDD. Me referi a frameworks que lhe dão subsídios para que você não perca tempo com o arroz e feijão.

Você pode ter complexas aplicações modeladas em DDD e mesmo assim utilizar recursos prontos de terceiros que lhe dão produtividade e não impactam em sua modelagem. CRUD é CRUD, se alguém me oferece isso de graça, eu não quero gastar nenhuma linha de código para isso... SE precisar e QUANDO precisar especializar este processo, isso será feito sem impacto algum. Este processo pode ser simples ao Domínio, mas é muito rotineiro o que acaba impactando na produtividade.

Obviamente, caso não trabalhe com algum framework que ofereça estes serviços, a melhor saída é se manter com a própria modelagem... ou desenvolver seu próprio framework caseiro que cuide disso.

Só para constar, uso também essa técnica do Lezinho. E as vezes meus repositórios vão para a view. (espero que não tenha inquisitores de plantão). Porém, na minha opinião não é DDD que estamos largando mão, já que é um Entity que estamos manuseando na view. Na minha opinião estamos deixando de usar a camada de aplicação para ganhar produtividade e simplicidade.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Acho válido tratar o CRUD deste jeito. E acho que pode ser a primeira abordagem em um projeto. Como o leozinho falou, se o CRUD complicar um pouco, ou aparecer a necessidade de portar a logica do CRUD para outra aplicação, aí pensamos em resolver.

Não vejo problemas na view conhecer e depender da persistência, afinal de contas a view nunca é portável. Mas acho que temos sempre que nos preocupar se o domain está completo e se ele é independente. Se tratar o CRUD "por fora" não impedir que o domain resolva o problema todo do sistema de forma independente, então tudo bem. Mas se um CRUD for fundamental para que o Domain resolva o problema do sistema, este deve ser tratado dentro do Domain, caso contrário não podemos dizer que estamos usando DDD. Também não seria errado, só não seria DDD.

Concordo também quando o Rodrigo diz que não estamos abrindo mão do DDD ao chamar o Repository direto da View, pois o repository pode ser um service simples. E talvez até faça sentido expor o repository para a view, pois que é responsável por forncer um objeto é o repository do tipo que queremos. Por exemplo, o responsável por fornecer um objeto Pessoa é o PessoaRepository e se a view precisa de um objeto desses, deve pedir ao repository. Mas isso não quer dizer que não estamos utilizando o Domain, pois o repository faz parte do Domain. Mas repito que regras de negócio devem ficar no Domain. Regras de infraestrutura não precisam.

E pra terminar, quero lembrar de que o Repository é diferente do DAO. Repository fica no Domain e o DAO na persistência, portanto o repository pode ser chamado de qualquer parte, mas a persistência deve ser preferencialmente isolada. O Repository deve encapsular a chamada à persistência para que possamos dizer que usamos DDD.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

sergiotaborda wrote:
Ups! a persistencia só guarda os identificadores, logo nunca ira guardas os dados.

Isso sim não é realista. Você não entendeu este ponto.

sergiotaborda wrote:
validaUsuario ( String username, char[] senha) (1)
validaUsuario ( Uusario usuario ) (2)

Eu não usei um exemplo que valida um usuário que ja existe no sistema. Meu exemplo cria um novo usuário. Nessas situações eu uso (1) na camada de app. para não ter que instanciar usuário (regra de app) na camada de visão.

sergiotaborda wrote:
Portanto (1) está certo na camada de aplicação e errado na de dominio. (2) pode estar certo em qualquer camada.

Desnecessário repetir mais uma vez de novo que não estou discutindo camada de domínio.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

sergiotaborda wrote:
A camada de aplicação não pode persistir o entity. O que ela faz é adicionar o entity no repositorio. ( o repositorio irá persistir se, e apenas se, for necessário)

sergiotaborda wrote:
Se eu fizer o que está sugerindo o sistema vai dar erro...

Você esperava o que ? você mudou o exemplo !

sergiotaborda wrote:
Vamos pensar que o usuario tem obrigatoriamente de ter uma password além de username e um perfil. Perfil é uma outra entidade.
(usuário não tem genero nem data de nascimento porque pode ser outro sistema)
A tela teria um campo para cada um com o perfil sendo um combobox.

criaUsuario(String nome, String pass, long perfilId);

Parece bom pra mim...mas também pode ser:

criaUsuario(String nome, String pass, Perfil perfil);

Neste caso o cliente não vai instanciar perfil para passar. Ele ja possui a referencia para tal objeto.

sergiotaborda wrote:
Depende do caso, existem diferentes "smarts" na ui.
Se a UI é MVC o model tem toda a liberdade de conversar com o resto do sistema usar as entities para isso.
A conversão entre os campos da tela e o entity é feita no proprio model ( que por def é um objeto de dominio) e portanto não ha nenhum problema nem ncessidade de usar façades com metodos com um monte de parametros.

Hmmm.. não vejo assim. A relação do M de MVC com o modelo de domínio é de dependência. Um usa o outro, mas um não é o outro. MVC, IMHO, é todo camada de visão.

Mas essa é outra discussão.

sergiotaborda wrote:
Resumindo, não defensável que uma aplicação baseada em DDD use metodos com parametros em vez das entities, já que fazer isso é usar um mecanismo de DTO que é contrário a DDD.

Eu só falei em tipos básicos da linguagem e objetos de domínio. DTOs é por sua conta !

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

carneiro wrote:
Contudo, pelo que vi a sua intençao é criar o usuário apenas com o essencial, no caso de seu exemplo o identificador login, e depois popular as demais informações, certo?

Certo. O login seria essencial neste caso pq ele deveria ser unico para o usuario que sera criado.

carneiro wrote:
Tudo isso para não permitir que sua entidade seja construída na camada de visão? Qual é o problema disso?

Exatamente. Se não houver camada de aplicacao não há problemas. Se ela existe prefiro usa-la.

carneiro wrote:
Você está realmente disposto a fazer um acesso adicional desnecessário ao mecanismo de persistência?

Pra mim não é desnecessário.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

carneiro wrote:Uma vez vi um código em que as informações iam e viam da visão para as demais camadas através mapas e coleções de tipos primitivos. Vi um caso de uma coleção de mapas, rsrs. O desenvolvedor argumentou que isso reduzia tremendamente o acoplamento, pois as classes de visão não conheciam as entidades do domínio.

Ou seja: ele confundiu acoplamento com coesão.

Ou não... talvez o objetivo dele fosse o desacoplamento mesmo...

O que talvez ele não soubesse é que não há problema na visao depender do dominio.

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

cmoscoso wrote:
Desnecessário repetir mais uma vez de novo que não estou discutindo camada de domínio.

Vc não precisa discutir camada de dominio, mas eu precisei exemplificar a diferença da assinatura dos métodos
conforme a camada em que são usados.

String , Date, Number , Boolean tb são DTO. Apenas são DTO com um so valor. DTO é um padrão de responsabilidade e uso e não de implementação. Quando vc escreve:

criaUsuario(String nome, String pass, long perfilId);

Vc está usando 3 DTO com 1 valor cada um. Se vc escrever

Map map
map.put("nome",nome);
map.put("pass",pass);
map.put("perfilId",perfilId);
criaUsuario(Map map);

Vc está usando 1 DTO com 3 valores.

Se vc está seguindo o tema do topico e tentando responder à pergunta "Instanciação de Entity, classe de domínio, DDD Evans, onde é correto?" então vc deve saber que usar DTO, qualquer que seja, é contra a filosofia DDD. Já que a UI pode conhecer o dominio (através do model do MVC) use-se a entidade e pronto.
Mas mesma a entidade pode estar sendo usado como DTO. Tudo bem desde que não exista um objeto cuja unica responsabilidade é ser um DTO. Um entidade, por definição, tem mais responsabilidades do que apenas portar dados.

Eu estou partindo da ideia de que a UI está sobre um modelo MVC. Se não estiver , ou o sistema é muito simples e nem ha o que discutir, ou está mal feito. O M do MVC não pertence ao UI, pertence ao dominio. Ele é responsavel por intrepretar alterações no modelo e passar isso à UI e intrepretar alterações na UI e passar ao modelo. O M do MVC tem acesso total às regras do negocio e do dominio e é a peça inteligente do UI (o smart)
A View e o Controlo são apenas automações da UI que nada têm a ver com o dominio.

This message was edited 1 time. Last update was at 27/11/2007 13:54:19

sergiotaborda wrote:
String , Date, Number , Boolean tb são DTO. Apenas são DTO com um so valor. DTO é um padrão de responsabilidade e uso e não de implementação. Quando vc escreve:

criaUsuario(String nome, String pass, long perfilId);

Vc está usando 3 DTO com 1 valor cada um. Se vc escrever

Map map
map.put("nome",nome);
map.put("pass",pass);
map.put("perfilId",perfilId);
criaUsuario(Map map);

Vc está usando 1 DTO com 3 valores.

DTOs são objetos tipo "estruturas de dados" que só possuem métodos relativos a armazenagem e obtencao desses dados.

String, Date, Boolean são imutáveis e possuem métodos que operam sobre os seus dados. Eles são Value Objects.

sergiotaborda wrote:
Se vc está seguindo o tema do topico...vc deve saber que usar DTO, qualquer que seja, é contra a filosofia DDD...Mas mesma a entidade pode estar sendo usado como DTO. Tudo bem desde que não exista um objeto cuja unica responsabilidade é ser um DTO.

Ficou confuso. Afinal pode ou não pode usar DTO?

Eu respondo:
Quando eu digo que esse tópico não é sobre a camada de domínio especificamente significa por exemplo que você poderia utilizar os DTOs na interface da sua camada de aplicacao sem prejudicar o seu modelo de domínio. Mas em nenhum momento eu defendi este uso de DTOs como parametros ou seja la como for, nem mesmo na camada de aplicacao.

sergiotaborda wrote:
Eu estou partindo da ideia de que a UI está sobre um modelo MVC. Se não estiver , ou o sistema é muito simples e nem ha o que discutir, ou está mal feito. O M do MVC não pertence ao UI, pertence ao dominio. Ele é responsavel por intrepretar alterações no modelo e passar isso à UI e intrepretar alterações na UI e passar ao modelo. O M do MVC tem acesso total às regras do negocio e do dominio e é a peça inteligente do UI (o smart)
A View e o Controlo são apenas automações da UI que nada têm a ver com o dominio.

Essa é a sua visão de MVC e camadas... Como já disse, eu não a compartilho.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

A propósito, estava eu procurando outra coisa e acabei achando o seguinte trecho na pag. 144

Eric Evans wrote:
ENTITY FACTORIES differ from VALUE OBJECT FACTORIES in two ways. VALUE OBJECTS are Immutable;
the product comes out complete in its final form. So the FACTORY operations have to allow for a full
description of the product. ENTITY FACTORIES tend to take just the essential attributes required to
make a valid AGGREGATE. Details can be added later if they are not required by an invariant.

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

cmoscoso wrote:
DTOs são objetos tipo "estruturas de dados" que só possuem métodos relativos a armazenagem e obtencao desses dados.

Não.

Data Transfer Object
An object that carries data between processes in order to reduce the number of method calls.
http://martinfowler.com/eaaCatalog/dataTransferObject.html

São objetos que transportam dados entre processos com o objetivo de reduzir o numero de chamadas a metodos. É o uso do objeto que o torna um DTO e não a estrutura interna o a interface do objeto. Sequer é
a necessidade de implementar Serializable.
Portanto, qualquer objeto usado para o fim de passar dados entre processos é um DTO.
Claro que , para ser util, o objeto tem que conter várias informações , mas isso não é uma necessidade para que o objeto seja considerado um DTO.

String, Date, Boolean são imutáveis e possuem métodos que operam sobre os seus dados. Eles são Value Objects.

Ser Value Object não tem nada a ver com DTO. Um objeto pode ser um VO e ser usado como um DTO.

sergiotaborda wrote:
Se vc está seguindo o tema do topico...vc deve saber que usar DTO, qualquer que seja, é contra a filosofia DDD...Mas mesma a entidade pode estar sendo usado como DTO. Tudo bem desde que não exista um objeto cuja unica responsabilidade é ser um DTO.

Ficou confuso. Afinal pode ou não pode usar DTO?

Vc pode criar entities na camada de apresentação , desde que nos objetos que , nessa camada , representam o dominio. Vc pode passar esses objetos para outros lugares como um DTO.
O que vc não pode fazer, em DDD, é criar um DTO burro , cujo objetivo é apenas transportar dados e que não contém nenhuma logica de dominio, ou seja, um objeto que não é uma Entidade.

Em outras palavras: vc pode passar Entities como se fosse DTO, mas não pode passar DTO como se fossem Entities.

Então a sua View pode criar DTO ( aliás o objeto Request é um DTO) e ele pode ser usado tranqüilamente na camada de UI (ou em outras camadas). Pode usar DTO dessa forma até que ele chegue no dominio. Aqui, sempre que houver comunicação com o dominio ( aka "o resto do sistema") Esses DTO têm que ser convertidos em Entidades( ou outros objetos de dominio - como VO ou Specifications ) de forma que o resto do sistema so veja Entities. Por isso que são necessárias Entity Factories.

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