Pergunta na lista UML-BR:
Boa tarde a todos,
Estava estudando o DDD (Domain Drive Design)…
Percebi que a camada de negócios deve ser um reflexo da realidade, para que
o sistema possa evoluir de maneira mais fácil (flexibilidade) conforme a
regra de negócios do cliente tb muda…
Por isso temos as entidades.. Por exemplo Funcionario, Departamento, etc…A duvida que eu tenho é a seguinte:
Vamos supor que eu tenha que exibir todos os funcionários em um JSP… eu
deveria criar um DTO do Funcionario e “mandar” para a camada de visão? ou
posso mandar o proprio objeto de negócio (o que na minha opinião é mais
pratico, já que eu não preciso duplicar código no DTO)?
Pois eu li o Artigo do Phillip Calçado e do Martin Fowler
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://www.martinfowler.com/bliki/AnemicDomainModel.html
onde eles dizem que não é bom criar DTO´s… e por isso estou confuso….O que vcs acham… para exibir as entidades em tela a camada de visão pode
ter contato com as entidades… ou vou ter que duplicar o código criando um
DTO para cada entidade?[...]
Então eu tb penso assim….
Mas pensando no lado negativo disso, imagine se eu tiver 50 JSP´s mostrando
os dados desse Funcionario…. Ai eu vou e faço uma refatoração no codigo
(talvez mudando metodos de uma classe pra outra, etc)…. vou ter que
verificar nos 50 JSP´s pra ver se não deu nenhum problema, ou até mesmo para
ajusta-los a nova mudança!!!!!
Talvez se eu criasse DTO´s para isso eu não teria esse problema pois os
DTO´s não mudariam…..
O que vcs acham disso…. faz sentido????valeu pessoal…..
Felipe Regalgo
Você poderia ter objetos de transferência apenas para a interface - DDD
não fala explicitamente sobre isso- mas existem algumas questões
práticas neste sentido:- Hierarquia duplicada desnecessariamente: Ao manter um DTO (VO é um
nome que já foi usado para DTOs mas não é mais) para isso você está
duplicando toda a sua hierarquia de classes, o que indica código
duplicado, tendo em dois ou mais lugares no seu sistema o mesmo
conceito implementado.- Mudanças: Da mesma maneira que se eu alterar minha classe de
negócios vou ter que alterar a interface sem DTOs, com DTOs a cada
mudança no meu modelo de negócios *eu tenho que alterar o DTO
correspondente em si*, logo você só transfere o problema de lugar mas
continua com ele -e com código duplicado que é *muito* ruim.- Se você pensar neste isolamento então precisa de DTOs para qualquer
coisa que não seja camada de negócios, logo vai precisar também para
persistência, por exemplo, caindo nos mesmos problemas acima para
outra camada.- Encapsulamento: OO exige que suas abstrações sejam encapsuladas, e
isso quer dizer que dificilmente a mudança na implementação de uma
classe vai afetar outras em tão grande escala. Quando isso acontece é
porque houve um grande refactoring ou uma grande mudança de conceito de
negócios, e isso -além de raro- vai afetar seu sistema com ou sem
DTOs. A diferença, como citando no primeiro item, é que sem DTOs você
não precisa se preocupar em mudar vários lugares, apenas a classe de
negócios.- Conceito de Negócios: DDD pressupõe que seu sistema modela ao mais
próximo da realidade possível. Se uma classe muda no modelo de
negócios é porque seu entendimento sobre o negócio mudou e
provavelmente alguma coisa na interface vai refletir isso.Em DDD temos os ContextMappers que mapeiam domínios diferentes que
precisam se comunicar. Esta é a abordagem normal para os casos onde se
percebe a necessidade de algo como um ‘DTO interno’.‘DTOs internos’ (”VOs”) são uma péssima prática, completamente não OO
e difundidas tristemente pela Sun para lidar com as falhas da
arquitetura de EJBs pré 3.0.[]s
Lendo o artigo veio me uma antiga dúvida na mente.
Definindo um problema para gerencia de pessoas… defino uma classe de pessoa.
[pessoa-------]
|-cpf———–|
|-nome——–|
|-motivoSaida|
—————|
|+sair()Z—–|
__________
Uma pessoa tem os atributos básicos cpf, nome etc,,, porém quando está pessoa sair (do projeto, local, ou qualquer outra coisa isso nesse momento não importa) ele deverá dizer o motivo da sua saida….
O que eu deveria fazer com este comportamento e estado de saida da pessoa? Parece estranho manter ele na mesma classe, sendo que ele quase não vai ser usado,,, parece fugir um pouco ao contexto do objeto pessoa em si.
Sobre isso, eu estou paranoico, não compreendendo direito ou tem algo “cheirando mal” nessa modelagem (ou pensamento)?
Esta pessoa continua na “empresa” e pode ser aproveitada em oturos projetos? Se não, ela pode voltar?
A princípio parece estranho sim, mas o que é a saída da pessoa? É uma entidade? É só um dado solto no espaço? Tudo depende do domínio.
Esta pessoa continua na “empresa” e pode ser aproveitada em oturos projetos?
Sim
Se não, ela pode voltar?
A princípio parece estranho sim, mas o que é a saída da pessoa?
É o ato de ela deixar um projeto…
É uma entidade?
A saída eu não enxerguei como uma entidade não
É só um dado solto no espaço?
Não ele é relacionado a saída de uma pessoa de um dado projeto.
Tudo depende do domínio.
Entendi, mas mesmo se o domínio (ou mini mundo) “parece” requer historicos do porquê as pessoas deixaram os projetos, poderia eu estar totamente errado ao ler isso dentro da entidade projeto ?
Se no entendimento do negócio, conhegui entender que eles tem uma entidade com uma propriedade quase nunca usada… o que devo fazer com ela? Lembrando que ela faz parte do dominio.
Com suas indagações me lembrei, eu entendi essa saida e motivo como um relacionamento entre pessoas e projetos, com a criação de uma outra entidade para representar essa “equipe tecnica” e suas relações entrada saida….
O foco é provalvmente se tenho um objeto no qual sua propriedade é quase nunca utilizada ou muito utilizada por outra entidade provavelmente ele é de outro entendimento (classe) ?
Desde já obrigado.
Ok, então saímso do domínio específico e entramos no conceito geral. Dados históricos geralmente usados uma vez a cada vida para fazer alguma auditoria ou coisa que o valha.
No mundo dos objetos estes dados estão ligados à entidade como quaisquer outros. Normalmente você teria uma lista de projetos pelos quais o funcionário passou e em algum lugar (uma classe associativa, talvez) o motivo e dados de entrada e saída.
Lembre-se que apra objetos não existe persistência. Sendo assim não existe dentre objetos conceitos como guardar e recuperar do banco de dados, tudo está *sempre* em memória.
Obviamente isto é inviável, então utilizamos um DataMapper ou algo que o valha para fazer o carregamento do bancod e dados ser o mais transparente possível. Bem, no caso dos dados históricos o seu DAO (ou Hibernate, ou JPA…) vai se responsabiliar por isso.
Do ponto de vista do objeto o histórico está disponível, mas ele não vaie star em memória. Quando alguém disparar um caso de uso que requeira o uso do histórico sua camada de persistência deve ser esperta o suficiente para recuperá-lo. Isso pode ser tão simples quanto um lazy-loading ou tão complexo quanto mandar um email para alguém pedindo a fita com os dados expurgados.
Mais uma vez obrigado!
[...] - Domain Driven Design : DDD, Shoes & Shoes, e tem uma matéria muito legal do Sérgio Lopes na Mundo Java 3 (que eu não tenho [...]