Bom dia a todos, cheguei a postar essa dúvida na própria lista de domain driven design mas ninguém teve uma resposta. Estava eu avaliando a ferramenta Hibernate tools, que pode ser útil quando se tem uma base de 200 tabelas e você não deseja escrever todos os mapeamentos na mão, até ai ok.
Uma das opções é Domain Java, que concordo que você não deva usar uma ferramenta pra gerar seus objetos de negócio. Sendo que isso não é o correto, a melhor alternativa seria gerar o mapeamento através do hibernate tools e construir uma camada de negócios que utilize esses objetos? Ou fazer todos os mapeamentos na mão até causar L.E.R?
Pois acredito que usar os objetos gerados pelo Hibernate tools seria, “bitolar” seu domain model a uma ferramenta.
Bom acredito que isso não seja uma dúvida técnica mas de design, agradeço qualquer opinião.
Bom não entendo muito de DDD, mas sempre acho interessante ter meus metodos de negocio junto aos Objetos que aquele negocio representa, por exemplo se eu tenho um Usuario o metodo que me diz se ele é autenticado eu deixaria no proprio usuario não preciso de um obj Autenticador, mesmo meu Usuario sendo um Entity. Não esquecendo tambem que alguem vai ter que executar esse metodo ne
pra responder isso vai o formato de um Domain Java em uma aplicação exemplo fornecida no site do hibernate
/**
* A user of the CaveatEmptor auction application.
*
* @author Christian Bauer
*/
@Entity
public class User implements Serializable, Comparable {
// ********************** Attributes ********************** //
// ********************** Accessor Methods ********************** //
// ********************** Common Methods ********************** //
// ********************** Business Methods ********************** //
}
Se você ver ai ele coloca os metodos de negocio junto, mas é claro que dependendo da sua arquitetura eventualmente você vai ter que ter uma classe auxiliar aqui, um Command (ptz!) ali
Eu acho que já deve ter havido umas mil discursos disso aqui (espero não apanha muito :P)
e se não me engano no blog do Calçado tem um artigo sobre isso. (Estou sem acesso a blog no cliente)
Cara, utilizar essas ferramentas para gerar suas classes, na minha opinião vai dar mais dor de cabeça e problema depois, pois no final suas classes representarão “problemas”, já fiz uma reversa e tive q fazer muito refactoring. O ideal é observar o modelo do banco de dados e avaliar como ele melhor se adequa ao seu negócio. O Hibernate Tolls ajuda, desde que vc tenha saco para revisar o ele fez e consertar as bizarrices geradas, ou o que não condiz com seu modelo.
é verdade tudo tem um preço, mas mesmo assim num banco com muitas tabelas vale a pena o refactoring se comparar a quantidade de codigo que ele vai gerar e você não vai precisar fazer na mão.
Faz muito tempo que eu não olho o hibernate tools mas criar classes à partir do modelo relacional é assumir que este representa a modelagem “correta” de seu sistema. Isso pode até ser verdade mas dada a discrepância entre um modelo OO e um Relacional acho que sim, você deve mapear um por um porque vai poder pensar na melhor maneira de representar tabelas com objetos.
Recentemente eu participei de um projeto com uma grande e intrincada base relacional legada. A decisão foi copiar o modelo relacional, usado por quase uma década para integração e outras coisas, em objetos e foi um arrependimento geral. Nós acabamos repetindo os erros do passado e foi necessário um esforço grotesco para refatorar as classes depois de prontas, visto que eram expostas via APIs remotas.
utilizei o Hibernate Tolls recentemente com o Eclipse Europa para engenharia reversa de mais ou menos 30 tabelas… NUNCA havia usado antes.
Li um pequeno tutorial se não me engano do próprio site do hibernate e ele funcionou perfeitamente. Acho que quem faz bizarrices somos nós na hora de usar a ferramenta, não é possível que ela funcione para mim e não funcione para o resto.
Recomendo fortemente o uso dela, contanto que você saiba usa-la.
[quote=pcalcado]Faz muito tempo que eu não olho o hibernate tools mas criar classes à partir do modelo relacional é assumir que este representa a modelagem “correta” de seu sistema. Isso pode até ser verdade mas dada a discrepância entre um modelo OO e um Relacional acho que sim, você deve mapear um por um porque vai poder pensar na melhor maneira de representar tabelas com objetos.
Recentemente eu participei de um projeto com uma grande e intrincada base relacional legada. A decisão foi copiar o modelo relacional, usado por quase uma década para integração e outras coisas, em objetos e foi um arrependimento geral. Nós acabamos repetindo os erros do passado e foi necessário um esforço grotesco para refatorar as classes depois de prontas, visto que eram expostas via APIs remotas.[/quote]
É, cada problema exige uma solução.
Dependendo do contexto realmente não é vantagem, só vai lhe atrapalhar, mas em geral lhe poupa tempo, claro estou contando que o banco esteja bem modelado.
O problema é que sempre é preciso refazer uma coisa aqui outra ali
Eu não sei se estou falando besteira então correções são sempre bem vindas. Mesmo que eu mapeie meu modelo relacional na mão, eu não estaria fazendo meu domain model orientado em específico a aquele modelo relacional? Vamos supor que seja um legado no qual a modelagem foi realizada por terceiros, mapear essas tabelas para objetos mesmo com os devidos cuidados, não seria restringir o pensamento a uma camada de negócios talvez incoerente? Pois o raciocínio seria orientado a uma modelagem pré existente.
Vamos supor por exemplo, que exista a tabela USUARIO_TIPO_SANGUINEO, ok, é um exemplo tosco. Então eu acabaria tentando mapear essa tabela, pra um objeto mesmo que pro meu domain model seja desnecessário? Não sei se me fiz claro, a intenção aqui é tirar essa duvida mesmo. Porque lendo aquele livro do Evans ele fala exatamente pra ter muito cuidado em não misturar modelo relacional com domain model como se fossem um só.
Como já disse, se tiver falando besteira, agradeço as correções. Assim aprendo mais.
[quote=pcalcado]Faz muito tempo que eu não olho o hibernate tools mas criar classes à partir do modelo relacional é assumir que este representa a modelagem “correta” de seu sistema. Isso pode até ser verdade mas dada a discrepância entre um modelo OO e um Relacional acho que sim, você deve mapear um por um porque vai poder pensar na melhor maneira de representar tabelas com objetos.
Recentemente eu participei de um projeto com uma grande e intrincada base relacional legada. A decisão foi copiar o modelo relacional, usado por quase uma década para integração e outras coisas, em objetos e foi um arrependimento geral. Nós acabamos repetindo os erros do passado e foi necessário um esforço grotesco para refatorar as classes depois de prontas, visto que eram expostas via APIs remotas.[/quote]
Você pdoe ter várias entidades relacionais que representam a mesma classe, várias classes que representam a mesma entidade relacional, etc. etc. etc. logo modelos relacional e oo podem (e geralmente vão) ser diferentes.
[quote]
Eu não sei se estou falando besteira então correções são sempre bem vindas. Mesmo que eu mapeie meu modelo relacional na mão, eu não estaria fazendo meu domain model orientado em específico a aquele modelo relacional?[/quote]
então se você vai fazer o modelo relacional novo, ai não precisa fazer engenharia reversa é mais aconselhavel mandar o hibernate gerar as tabelas pra você (se você pudar por que tem lugares que tem convensões de banco) ou fazer o modelo relacional baseado no seu modelo.
É nesse caso você tem que ver o que é melhor para você, se for dar mais trabalho auto gerar os Domain Java ou deixar seu modelo pobre não o faça, mas no caso do HT você pode escolhe quais tabelas usar então aquelas onde você vai basicamente fazer CRUDs você poderia gera-las automaticamente para não perder tempo ou ainda deixar algumas tabelas como a que você falou de lado, talvez até fazer com que aquele campo seja um Enum no lugar de um Entity.
Não há o melhor jeito de fazer tudo (infelizmente), mas há um bom jeito de fazer algumas coisas, no caso que o Calçado sitou não foi muito produtivo fazer o modelo OO baseado no modelo Relacinal, mas comigo tive varios casos que o que eu faria em dias fiz com dois cliques com o HT e outras ferramentas Case.
Você pdoe ter várias entidades relacionais que representam a mesma classe, várias classes que representam a mesma entidade relacional, etc. etc. etc. logo modelos relacional e oo podem (e geralmente vão) ser diferentes.[/quote]
Então nesses casos por exemplo não vale a pena, você gerar 5 Classes e ter q apagar 4 por que uma unica classe representa as 5 tabelas, ou ainda gerar 1 classes e ter que apagar metade do codigo para colocar objetos Embedded, mas aquela tabela (e as outras 465441) que você só vai fazer CRUD ou os atributos são os mesmos que a tabela (ex Usuario, Cliente, Produto) essas valem a pena
Você pdoe ter várias entidades relacionais que representam a mesma classe, várias classes que representam a mesma entidade relacional, etc. etc. etc. logo modelos relacional e oo podem (e geralmente vão) ser diferentes.[/quote]
Se você tem um modelo de classes que igual - ou quase - ao seu modelo relacional, para que usar DDD? Não seria melhor e mais simples algo como um Active Record?
[quote=Maurício Linhares]E o que é que uma coisa tem haver com a outra?
Active record é um padrão de projeto, ddd é um modo de se desenvolver software, eles não são excludentes.[/quote]
Onde eu lia DDD compreendia Domain Model… ainda estou devendo a mim mesmo a leitura do Evans. De qualquer modo, se o seu modelo de objetos é um espelho do seu modelo relacional, seu “modo de desenvolver software” será bem mais “data-driven” que “domain-driven”.
Sim, Domain Driven Design é sobre Domain Models mas dá no mesmo: Domain Model geralmente utiliza Data Mapper mas não consigo ver nenhum impedimento para usar Active Record. Na verdade o Ruby on Rails faz bastante isso.
[quote=Rodrigo Manhães]
Onde eu lia DDD compreendia Domain Model… ainda estou devendo a mim mesmo a leitura do Evans. De qualquer modo, se o seu modelo de objetos é um espelho do seu modelo relacional, seu “modo de desenvolver software” será bem mais “data-driven” que “domain-driven”.[/quote]
A escolha por uma solução DDD se da por outras variaveis (requisitos da aplicacao e até expertise), PAdroes para integração com o “modelo relacional” como data mapper ou active record podem ser utilizados seja qual for o caminho adotado (domain model ou modelo anemico).
