Postei um novo artigo no wiki sobre o uso de VOs/BOs. Sim, mais um artigo sobre a prática questionável de utilizar “classes de dados” e “classes de lógica” em vez de objetos de verdade. A idéia é ter uma referência para indicar quando alguém citar “VO” ou “BO” em uma conversa.
This entry was posted
on Tuesday, January 2nd, 2007 at 1:20 am and is filed under arquitetura, artigos, engenharia, java, orientacao.a.objetos, programando.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.
17 Responses to “VO, BO e Tudo Mais que você não deveria utilizar”
O artigo aponta problemas mas não indica nenhuma solução… No caso de uma aplicação C/S, onde o cliente precisa acesso ao modelo de objetos que vive no servidor, como evitar precisar de transfer objects?
Na verdade usar DTO (o nome ‘generico’ do TO) neste cenário não é um problema, é uma técnica válida. O problema é utilizar a dupla VO/BO em ambientes não distribuídos.
Concordo plenamente com vc sobre o artigo do BO junto TOs, mas que realmente é que o pessoal tem usado, independente do acloplamento gerado entre eles !! Outra coisa, importante é que este modelo sujerido pelo CORE J2EE é o que realmente tem oferecido a flexibilidade e escalabilidade em projetos EJB…
Tambem sou fã do Martin Fowler e estou de acordo com visão dele sobre o Modelo Anemico…mas se lembre que a pratica sempre supera a biografia…
Quantos projetos com EJB realmente precisam de EJB? Se o modelo EJB fosse escalável e flexível não teria sido reescrito noa versão 3.0 ;)
Mas sim, DTOs/TOs são extremamente importantes para projetos com EJB 2.1, *desde que envolvam chamadas remotas*,este ponto não é questionado. Note que boa parte dos projetos EJB sequer fazem chamadas remotas.
Nesse modelo, de quem é a responsabilidade de metodos como:
- buscarTodosUsuariosSemGrupo();
Da classe Usuario? Mesmo que as regras desse metodo não tenham nada a ver com o objeto usuário instanciado? (já que o retorno é uma lista de vários usuários)…
É correto em OO o metodo de uma classe Usuario tratar coisas de outros usuários?
Complicando mais ainda, e quando além de buscar os usuários, a regra de negocio é responsável por dar um loop em cada um e setar um flag. Isso não é cenário para um BO? Um lugar onde se possa manipular dados e objetos do tipo Usuario, de acordo com as regras de negócio do sistema.
Ou a classe Usuario deve ser responsável por tratar outros usuários?
Depois de ler o artigo da Mundo Java 17, entendi a resposta para a minha pergunta. E é exatamente da forma que eu já utilizo.
Usando Gerentes.
Porém eu não vejo Gerentes como algo muito distante de BO’s.
Pra mim o Gerente tem parte (pelo menos o fluxo) das regras de negocio.
Você diz no seu artigo da revista que um Service ou Gerente “não possuem estado e não executam Regras de Negócio, apenas definem a ordem que estas são executadas.”
Mas na minha visão a ordem de execução já é de certa forma uma regra.
Então ao ler esse seu artigo “VO, BO e Tudo Mais que você não deveria utilizar” deu a entender que você estava propondo algo legal (Domain Model), mas de forma muito radical, colocando tudo dentro dos POJOS. E nem tudo está nos POJOS. O fluxo das regras de negocio e metodos que envolvem chamadas a vários objetos estão nos Gerentes, que não são citados nesse artigo, somente na revista.
Então isso confundiu um pouco o entendimento, na minha opinião.
Mas bacana cara… =)
Na verdade o conceito de BO e Service (o que você chama de ‘Gerente’) é *muito* diferente.
Um BO como descrito no artigo é um objeto que concentra regras de negócio sobre um dado conceito, como UsuarioBO que contêm regras de negócios sobre a entidade Usuario.
Um Service no conceito de Domain Driven Design é um Façade que abstrai o fluxo de interações necessárias para realizar um dado fluxo de negócios. Isso quer dizer que, ao contrário do BO, o Service não executa regra alguma, apenas chama os objetos de domínio que possuem tais regras.
Resumindo: não, não existem regras de negócio nos Services e acredito que o artigo da MJ deixa isso bem claro, inclusive com exemplos.
Acredito também que você confundiu um pouco o conceito de POJO. Nada impede que um BO ou VO seja um POJO, bem como que não seja, ou qualquer classe de domínio. O artigo não fala sobre POJOs, fala sobre modelagem. Talvez eu devesse incluir uma seção sobre esta confusão de POJOs, VO, DTO e BO.
Não calçado, você que não entendeu o que eu falei. Falei que o Gerente tem o fluxo das regras de negocio do BO. E esse fluxo não deixa de ser uma regra.
Transferencia de valores: se em vez de tirar da ContaA e passa para a ContaB, fizer o contrário, o sistema estaria alterando uma regra de negocio. E essa regra não fica no Domain (que eu chamei de POJO). Fica no Gerente. Então o gerente de certa forma também tem regra. Porém o foco dele é diferente. Como eu disse ele controla o fluxo.
Seu artigo fala de Domain Model, então fala de POJO, porque POJO é quase qualquer tipo de objeto (claro não tem extends, nem relacionamento com nenhum framewok). Por isso mesmo eu citei POJO me referindo ao Domain. Os objetos do Domain são POJOs.
Se você seguir este raciocínio a interface também é regra de negócio. Ao popular um formulário de uma maneira x você tem um comportamento, de uma maneira Y de outro. É por isso que existe a Camada de Aplicação (onde Services e demains instrumentos de fluxo residem) e de Negócios. O fluxo em si diz como os objetos são estimulados. A regra de negócio é o que acontece quando a transferência é feita, seja lá quem estimulou o objeto de negócios.
Page-Jones tem uma definição ótima para isso separando objetos em ‘Domínios’ (não confundir com Domain Model). O Domain Model fica no domínio de negócios, o Service no domínio de aplicação.
As regras de negócio da aplicação são dadas pela soma das regras do domínio de aplicação com as do domínio de negócios (além de outros como o fundamental), mas as regras do domínio de negócios não estão rpesas com as da aplicação.
Você pode, se quiser, dizer que a Camada de Aplicação tem regras de negócio e definir que o fluxo de interações é regra de negócio, mas o domínio é outro.
Um BO não faz este tipo de coisa. Um BO executa regras de negócio. Se você chama Services de BO estamos apenas dando nomes diferentes para a mesma coisa e isso pode estar gerando esta confusão.
Se para você um BO não contêm regra de negócios, apenas estimula objetos, sua definição não é a mesma do artigo, apenas isso.
Quanto á POJO, eles não são quase qualquer tipo de objeto e não são mencionados no artigo. Nada impede que você implemente um domínio não anêmico com um framework, por exemplo. Não é ser ou não um POJO que define um modelo elaborado ou anêmico, ou qualquer tipo de Domain Model.
Mas calçado vc está forçando um pouco… A parte da camada de aplicação, os dados já são esperados, e não importa em que ordem venham. Tem as validações e quando chegar nas regras pouco importa quem veio primeiro, desde que obedeça o que é experado. Isso não muda as regras. Dados não muda regra. Regra é código.
“As regras de negócio da aplicação são dadas pela soma das regras do domínio de aplicação com as do domínio de negócios”
Essa é a definição perfeita pra mim. E foi o que eu disse, porém com outras palavras. As regras *não* estão só no dominio dos negócios.
“Você pode, se quiser, dizer que a Camada de Aplicação tem regras de negócio e definir que o fluxo de interações é regra de negócio”
Então ok :) Foi isso que eu disse.
“Se você chama Services de BO estamos apenas dando nomes diferentes para a mesma coisa e isso pode estar gerando esta confusão.
Não. Não disse isso. Só disse que os Services tem o fluxo das regras que geralmente está no BO. A regra mesmo está no Domain. Mas o fluxo está no Services.
Imagina um metodo de inativar usuário. No BO, ele faz tudo, pega todos os usuário, seta os atributos de cada um etc.
O que eu disse é que com Domain Model a regra de inativar() está no usuario, mas o fluxo de buscar todos (que era do BO) e chamar esse metodo de inativar está no Service.
Falei isso para dizer que você não citou Services nesse artigo, então pelo menos para mim confundiu um pouco, porque pareceu que tudo estava no Domain Model, e como dissemos nessa conversa, nem tudo está.
Sobre POJO, no contexto dessa conversa ele era o Domain, o objeto Usuario do seu artigo.. Então se Usuario é um POJO, logo isso foi citado indiretamente, ou pelo menos é possível entender qual classe são POJOs nos exemplos do artigo. Você só está forçando para não entender o que eu estou falando =)
POJO (no meu texto) = Usuario do seu artigo, ok?
Apesar das confusões de palavras, acho que a gente está chegando em um ponto em comum. E isso é bacana =)
Não, não, regra de negócio está relacionada a tudo que acotnece, não apenas código. A implementação da regra de negócio em código que deve costuma deve ser feito no Domain Model.
As regras da aplicação não estão no domínio de negócios, ótimo, mas os dois artigos falam de camadas, especificamente da camada de negócios.
Sobre ‘tudo estar no Domain Model’, isto também varia. Nada impede que existam Services no Domain Model e que eles controlem os flucos internos do domínio.
Sobre POJO, ok mas esse é o contexto que você criou e usou, não eu ;)
Acho que a conclusão passa por: Services != BOs
Services são conceitos de domínio, não são artificiais e podem conter estado, ao contrário de BOs.
Sobre ‘tudo estar no Domain Model’, isto também varia. Nada impede que existam Services no Domain Model e que eles controlem os flucos internos do domínio.
Beleza. Mas o service esteja onde estiver, não foi citado no “Evitando VOs e BOs”. Então lendo só ele ficaram algumas dúvidas. Mas ao ler a revista complementou o assunto eu entendi o que você estava querendo dizer ok?
Como eu citei eu já acho que Services != BOs, porém o Service tem o fluxo de algumas regras que eram no BO (mas não as regras). Então pra mim a conclusão é quem nem tudo está no POJO do Usuario como eu tinha entendido a primeira vez que eu li.
Agora, sobre regra de negocio, se me permitir, eu penso diferente. Pra mim é código. Não é imagem, não é HTML, não é dado. Em um sistema é código. Antes do sistema estar pronto era parte dos requisitos, modelagem etc. Mas no sistema não vejo com algo diferente de código. Dado seja como vier não é regra nem muda as regras (as regras já foram escritas previamente, antes dos dados) =)
Tipo, estou conhecendo o wiki e o blog agora, mas gostei de alguns assuntos.
O artigo aponta problemas mas não indica nenhuma solução… No caso de uma aplicação C/S, onde o cliente precisa acesso ao modelo de objetos que vive no servidor, como evitar precisar de transfer objects?
Oi, Rafael,
Na verdade usar DTO (o nome ‘generico’ do TO) neste cenário não é um problema, é uma técnica válida. O problema é utilizar a dupla VO/BO em ambientes não distribuídos.
Quanto ás soluções, convido você a dar uma lida nos outros artigos, especialmente o Desenvolvendo Sistemas OO Com Padrões de Negócio.
[]s e obrigado pelo feedback!
Concordo plenamente com vc sobre o artigo do BO junto TOs, mas que realmente é que o pessoal tem usado, independente do acloplamento gerado entre eles !! Outra coisa, importante é que este modelo sujerido pelo CORE J2EE é o que realmente tem oferecido a flexibilidade e escalabilidade em projetos EJB…
Tambem sou fã do Martin Fowler e estou de acordo com visão dele sobre o Modelo Anemico…mas se lembre que a pratica sempre supera a biografia…
Fernando Franzini - SCJA, SCJP e SCWCD.
Eae cara… soh faltou um agradecimento ai por ter enchido seu saco sobre esse tema rsrsrsrs…
onde foi discutido amplamente aqui:
http://www.guj.com.br/posts/list/44469.java
O bom que o David levou mais alto a discução, inclusive me ajudando melhor no esclarecimento…
fico muito grato pelo artigo, acho que será de grande avalia para muitos, pelo fato de o problema existir…
Agora ficou bastante claro o porque do tal BO . Parabéns pela pesquisa!
vc é o cara! ehehe , abraços
Fernando,
Quantos projetos com EJB realmente precisam de EJB? Se o modelo EJB fosse escalável e flexível não teria sido reescrito noa versão 3.0 ;)
Mas sim, DTOs/TOs são extremamente importantes para projetos com EJB 2.1, *desde que envolvam chamadas remotas*,este ponto não é questionado. Note que boa parte dos projetos EJB sequer fazem chamadas remotas.
Nesse modelo, de quem é a responsabilidade de metodos como:
- buscarTodosUsuariosSemGrupo();
Da classe Usuario? Mesmo que as regras desse metodo não tenham nada a ver com o objeto usuário instanciado? (já que o retorno é uma lista de vários usuários)…
É correto em OO o metodo de uma classe Usuario tratar coisas de outros usuários?
Complicando mais ainda, e quando além de buscar os usuários, a regra de negocio é responsável por dar um loop em cada um e setar um flag. Isso não é cenário para um BO? Um lugar onde se possa manipular dados e objetos do tipo Usuario, de acordo com as regras de negócio do sistema.
Ou a classe Usuario deve ser responsável por tratar outros usuários?
questions, questions…
“A coestão das classes de lógica (BOs)”
> coesão, não? ;)
Ops, corrigido!
Esse artigo é uma excelente resposta para algumas pergutnas que apareceram em um post que eu fiz sobre design patterns:
http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/
Parabéns Calçado! Denovo um artigo com profundidade.
Oi, J++ (nossa, que lembranças esse nick traz…),
Dê uma olhada neste arigo:
Desenvolvendo Sistemas OO Com Padrões de Negócio
Ele tem respostas para você ;)
Opa calcado….
Depois de ler o artigo da Mundo Java 17, entendi a resposta para a minha pergunta. E é exatamente da forma que eu já utilizo.
Usando Gerentes.
Porém eu não vejo Gerentes como algo muito distante de BO’s.
Pra mim o Gerente tem parte (pelo menos o fluxo) das regras de negocio.
Você diz no seu artigo da revista que um Service ou Gerente “não possuem estado e não executam Regras de Negócio, apenas definem a ordem que estas são executadas.”
Mas na minha visão a ordem de execução já é de certa forma uma regra.
Então ao ler esse seu artigo “VO, BO e Tudo Mais que você não deveria utilizar” deu a entender que você estava propondo algo legal (Domain Model), mas de forma muito radical, colocando tudo dentro dos POJOS. E nem tudo está nos POJOS. O fluxo das regras de negocio e metodos que envolvem chamadas a vários objetos estão nos Gerentes, que não são citados nesse artigo, somente na revista.
Então isso confundiu um pouco o entendimento, na minha opinião.
Mas bacana cara… =)
Oi, J++,
Na verdade o conceito de BO e Service (o que você chama de ‘Gerente’) é *muito* diferente.
Um BO como descrito no artigo é um objeto que concentra regras de negócio sobre um dado conceito, como UsuarioBO que contêm regras de negócios sobre a entidade Usuario.
Um Service no conceito de Domain Driven Design é um Façade que abstrai o fluxo de interações necessárias para realizar um dado fluxo de negócios. Isso quer dizer que, ao contrário do BO, o Service não executa regra alguma, apenas chama os objetos de domínio que possuem tais regras.
Resumindo: não, não existem regras de negócio nos Services e acredito que o artigo da MJ deixa isso bem claro, inclusive com exemplos.
Acredito também que você confundiu um pouco o conceito de POJO. Nada impede que um BO ou VO seja um POJO, bem como que não seja, ou qualquer classe de domínio. O artigo não fala sobre POJOs, fala sobre modelagem. Talvez eu devesse incluir uma seção sobre esta confusão de POJOs, VO, DTO e BO.
[]s
Não calçado, você que não entendeu o que eu falei. Falei que o Gerente tem o fluxo das regras de negocio do BO. E esse fluxo não deixa de ser uma regra.
Transferencia de valores: se em vez de tirar da ContaA e passa para a ContaB, fizer o contrário, o sistema estaria alterando uma regra de negocio. E essa regra não fica no Domain (que eu chamei de POJO). Fica no Gerente. Então o gerente de certa forma também tem regra. Porém o foco dele é diferente. Como eu disse ele controla o fluxo.
Seu artigo fala de Domain Model, então fala de POJO, porque POJO é quase qualquer tipo de objeto (claro não tem extends, nem relacionamento com nenhum framewok). Por isso mesmo eu citei POJO me referindo ao Domain. Os objetos do Domain são POJOs.
Olá,
Se você seguir este raciocínio a interface também é regra de negócio. Ao popular um formulário de uma maneira x você tem um comportamento, de uma maneira Y de outro. É por isso que existe a Camada de Aplicação (onde Services e demains instrumentos de fluxo residem) e de Negócios. O fluxo em si diz como os objetos são estimulados. A regra de negócio é o que acontece quando a transferência é feita, seja lá quem estimulou o objeto de negócios.
Page-Jones tem uma definição ótima para isso separando objetos em ‘Domínios’ (não confundir com Domain Model). O Domain Model fica no domínio de negócios, o Service no domínio de aplicação.
As regras de negócio da aplicação são dadas pela soma das regras do domínio de aplicação com as do domínio de negócios (além de outros como o fundamental), mas as regras do domínio de negócios não estão rpesas com as da aplicação.
Você pode, se quiser, dizer que a Camada de Aplicação tem regras de negócio e definir que o fluxo de interações é regra de negócio, mas o domínio é outro.
Um BO não faz este tipo de coisa. Um BO executa regras de negócio. Se você chama Services de BO estamos apenas dando nomes diferentes para a mesma coisa e isso pode estar gerando esta confusão.
Se para você um BO não contêm regra de negócios, apenas estimula objetos, sua definição não é a mesma do artigo, apenas isso.
Quanto á POJO, eles não são quase qualquer tipo de objeto e não são mencionados no artigo. Nada impede que você implemente um domínio não anêmico com um framework, por exemplo. Não é ser ou não um POJO que define um modelo elaborado ou anêmico, ou qualquer tipo de Domain Model.
Mas calçado vc está forçando um pouco… A parte da camada de aplicação, os dados já são esperados, e não importa em que ordem venham. Tem as validações e quando chegar nas regras pouco importa quem veio primeiro, desde que obedeça o que é experado. Isso não muda as regras. Dados não muda regra. Regra é código.
“As regras de negócio da aplicação são dadas pela soma das regras do domínio de aplicação com as do domínio de negócios”
Essa é a definição perfeita pra mim. E foi o que eu disse, porém com outras palavras. As regras *não* estão só no dominio dos negócios.
“Você pode, se quiser, dizer que a Camada de Aplicação tem regras de negócio e definir que o fluxo de interações é regra de negócio”
Então ok :) Foi isso que eu disse.
“Se você chama Services de BO estamos apenas dando nomes diferentes para a mesma coisa e isso pode estar gerando esta confusão.
Não. Não disse isso. Só disse que os Services tem o fluxo das regras que geralmente está no BO. A regra mesmo está no Domain. Mas o fluxo está no Services.
Imagina um metodo de inativar usuário. No BO, ele faz tudo, pega todos os usuário, seta os atributos de cada um etc.
O que eu disse é que com Domain Model a regra de inativar() está no usuario, mas o fluxo de buscar todos (que era do BO) e chamar esse metodo de inativar está no Service.
Falei isso para dizer que você não citou Services nesse artigo, então pelo menos para mim confundiu um pouco, porque pareceu que tudo estava no Domain Model, e como dissemos nessa conversa, nem tudo está.
Sobre POJO, no contexto dessa conversa ele era o Domain, o objeto Usuario do seu artigo.. Então se Usuario é um POJO, logo isso foi citado indiretamente, ou pelo menos é possível entender qual classe são POJOs nos exemplos do artigo. Você só está forçando para não entender o que eu estou falando =)
POJO (no meu texto) = Usuario do seu artigo, ok?
Apesar das confusões de palavras, acho que a gente está chegando em um ponto em comum. E isso é bacana =)
Não, não, regra de negócio está relacionada a tudo que acotnece, não apenas código. A implementação da regra de negócio em código que deve costuma deve ser feito no Domain Model.
As regras da aplicação não estão no domínio de negócios, ótimo, mas os dois artigos falam de camadas, especificamente da camada de negócios.
Sobre ‘tudo estar no Domain Model’, isto também varia. Nada impede que existam Services no Domain Model e que eles controlem os flucos internos do domínio.
Sobre POJO, ok mas esse é o contexto que você criou e usou, não eu ;)
Acho que a conclusão passa por: Services != BOs
Services são conceitos de domínio, não são artificiais e podem conter estado, ao contrário de BOs.
Sobre ‘tudo estar no Domain Model’, isto também varia. Nada impede que existam Services no Domain Model e que eles controlem os flucos internos do domínio.
Beleza. Mas o service esteja onde estiver, não foi citado no “Evitando VOs e BOs”. Então lendo só ele ficaram algumas dúvidas. Mas ao ler a revista complementou o assunto eu entendi o que você estava querendo dizer ok?
Como eu citei eu já acho que Services != BOs, porém o Service tem o fluxo de algumas regras que eram no BO (mas não as regras). Então pra mim a conclusão é quem nem tudo está no POJO do Usuario como eu tinha entendido a primeira vez que eu li.
Agora, sobre regra de negocio, se me permitir, eu penso diferente. Pra mim é código. Não é imagem, não é HTML, não é dado. Em um sistema é código. Antes do sistema estar pronto era parte dos requisitos, modelagem etc. Mas no sistema não vejo com algo diferente de código. Dado seja como vier não é regra nem muda as regras (as regras já foram escritas previamente, antes dos dados) =)
Tipo, estou conhecendo o wiki e o blog agora, mas gostei de alguns assuntos.