[quote=fabio.patricio]
Um pequeno detalhe.
produto se salvar != vai para o estoque
Sao coisas bem diferentes.
]['s[/quote]
Tudo bem, que seja, o que quiz atentar é o fato do produto ‘fazer coisas d+’, entende?
A Paz!
[quote=paulohbmetal][quote=fabio.patricio]
Um pequeno detalhe.
produto se salvar != vai para o estoque
Sao coisas bem diferentes.
]['s[/quote]
Tudo bem, que seja, o que quiz atentar é o fato do produto ‘fazer coisas d+’, entende?
A Paz![/quote]
Entendo, mas mesmo assim nao concordo.
]['s
O que ele quis dizer é que objetos foram criados para isso.
Sua divisão é anti-OO. Se continuar assim é fácil chegar ao ponto onde se cria uma classe para cada método, numa sequência de Commands. Dividir responsailidades é encontrar objetos nas quais estas devem ser acomodadas.
Ninguém está falando de Model-Driven Development ainda mas simplesmente de OO. Você pode ter um domínio modelado de forma completamente fora dos princípios do MDD mas ainda assim deve ter objetos e não BO/VO.
Creio que ninguém aqui defende isso como a melhor solução sempre, tanto que alguns posts atrás falávamos sobre quando usar um Transaction Script ao invés de um Domain Model. O problema é que você está defendendo que isso é Orientação a Objetos e não, não é.
Mais de cinquenta mil classes de domínio? Certamente essa modelagem precisa ser revista. Um sistema com esse número de classes no mínimo deveria ser dividido em uns cinco.
Eu posso te dar uma lista extensa de sistemas construídos com princípios básicos de OO, dentre os que já trabalhei ou que conheço a estrutura, mas fiquemos com o meu mais recente: http://video.globo.com que integra desde a produção de um vídeo por uma dezena de canais de TV diferentes até o consumo, com recursos de integração via REST, RMI, sockets e requisitos de performanc euqe fazem bancos parecerem blogs.
Aliás o grande objetivo de OOP sempre foi ajudar a gerenciar complexidade. Sistemas grandes são os que mais se beneficiam da organização de dados e funcionalidade em objetos ao invés de termos funções e estruturas de dados como você descreveu (que é algo que se faz em C e Pascal, não em linguagens OO).
Não senhor. Princípio básico de análise de sistemas: abstraia o mundo. Você só deve modelar as características do Produto que forem relevantes ao seu sistema.
[quote=paulohbmetal]
Claro que os objetos devem ser colaborativos, e muitas vezes para realizar uma lógica de negócio é preciso que eles se relacionem. Para isso existem “Services”. Lembre-se que os Services tbm não executam lógica de negócio, apenas fazem a ponte de iteração entre os objetos de negócio, orquestrando suas chamadas e fluxo de execução (mas a lógica continua nos objetos de negócio), para determinado caso de uso seja satisfeito. [/quote]
Para um objeto (estado+comportamento e não as estruturas de dados que você se referiu) executar uma ação qualquer ele vai delegar e colaborar com outros objetos. NotaFiscal delega para Produto, por exemplo.
Na verdade EJBs fazem o extremo oposto disso. A única diferenças entre o que você fez e um Entity Bean é que você preovavelmente usa um DAO enquanto o Entity se salva, mas os problemas de modelagem são os mesmos: funções (Session Beans para eles, classes ‘Business’ para você) manipulando estruturas de dados (Entity Beans lá, classes ‘domain’ para você).
Produto se salvar ou ter alguém que salve produto é uma discussão válida mas ainda não chegamos nela. Salvar, recuperar, etc. não são lógica de negócio e nós ainda estamos definindo o que é um objeto 
Aproveitando o topico pra fazer uma pergunta:
Quem me devolve a lista de Produtos? ProdutosRepository?
Posso chamar o metodo getProdutoById direto da UI?
Se você está aplicando Domain-Driven design, sim.
[quote=fabiocsi]
Posso chamar o metodo getProdutoById direto da UI?[/quote]
Ele fica num Repository? Se sim e você não tem uma Camada de aplicação bem definida pode, se não não pode.
Se o método fica num Repositorio tire o ‘Product’ do nome do método, o repositorio já é de produtos
Entendi. Show.
Então na verdade essa camada de “negócio” ( infelizmente eu aprendi desse jeito ), esses metodos de negocios deveriam estar dentro
do proprio objeto Produto certo?
Estou concordando tambem que nao tem sentido jogar metodos de produtos numa classe (Ex: ProdutoBusiness) realmente nao tem nada
a ver com OO.
Vou te dizer que esses dias tive que fazer um controle de usuarios aqui e coloquei attributos E logica tudo na mesma
classe e fez MUUUUUUUITO mais sentido pra mim.
Agora, pcalcado, uima pergunta (que pode parecer idiota):
O que seria esssa camada de aplicação que vc mencionou?
Olá Phillip. Não foi o “paulohbmetal” que mencionou sobre os Services e sim eu. Apenas citei a Service Layer como uma ponte stateless de atribuições para os objetos em determinados casos de uso entre a camada de aplicação e a camada de negócio. Por isso citei “orquestrando suas chamadas e fluxo de execução”.
E claro:
… quando disse modelar os “n” comportamentos de “Produto” no mundo real, me referia aqueles necessários p/ a aplicação (como não poderia deixar de ser).
Talvez eu não soube me expressar bem.
Tudo bem, ratificado.
É, a teoria tá linda! Mas ainda não vi exemplos, como fiz.
É lógico que estou falando de todas as classes da aplicação. Fala sério. Não quero modelar o mundo. 
Olha, longe de mim querer desmerecer seu trabalho, que deve ser muito interessante e importante. Mas o ambiente que me refiro (e trabalho) é muito mais complexo que isso. Imagine vc trabalhar num ambiente em que várias aplicações de domínios distintos devem colaborar entre si. Tais aplicações vão desde RH a Financeiro de um Estado inteiro.
Eu não disse isso!
[quote=pcalcado]
Nem isso! :shock:
[quote=pcalcado]
Na verdade EJBs fazem o extremo oposto disso. A única diferenças entre o que você fez e um Entity Bean é que você preovavelmente usa um DAO enquanto o Entity se salva, mas os problemas de modelagem são os mesmos: funções (Session Beans para eles, classes ‘Business’ para você) manipulando estruturas de dados (Entity Beans lá, classes ‘domain’ para você).[/quote]
É mais meu bean é burro e não se salva.
[quote=pcalcado]
Produto se salvar ou ter alguém que salve produto é uma discussão válida mas ainda não chegamos nela. Salvar, recuperar, etc. não são lógica de negócio e nós ainda estamos definindo o que é um objeto ;)[/quote]
Ok, ainda (devemos) chegaremos lá.
Desculpe, mas não é apenas teoria. Não existem argumentso na sua frase, é apenas um tentativa fútil de desmerecer um argumento, se não funciona na prática ao menos diga por quê.
Uma aplicação tem cinquenta mil classes? Imagino que você está contando as classes que usas da API do Java, do seus frameworks favoritos…certo? Cinquenta mil classes feitas pela sua equipe indicam problemas de modelagem, já sabemos de um problema: que a dupla BO/VO que você usa infla o número.
Ai, ai, lá vamos nós com ‘o meu pipi é maior que o seu’. Além de um portal ser um dos ambientes mais extremos que conheço (e veja só: aqui não temos apenas domínios distintos colaborando, temos empresas distintas com equipes, tecnologias e interesses distintos) eu já trabalhei com uma série de domínios que acredito você consideraria ‘complexos’ como billing de telecom (você não tem idéia do número de integrações com protocolos de todos os níveis de todos os fornecedores), logística (da maior empresa de mineração do mundo) e análise de risco (analisando todas as transações realizadas nas bolsas para projetar gráficos e tomar decisões em tempo real de compra e venda), manufatura (gerencie uma fábrica de computadores Fortune 100), seguros e previdência privada, bancos, petróleo, gerenciamento de informações de mega-empresas… Sinceramente a quantidade de dinheiro que trafega por alguns estes sistemas é maior que o PIB de diversos estados brasileiros.
Mas ok, eles podem ser simples. Já viu a lista de clientes da empresa do cv, famosa por adotar e mesmo evangelizar design com qualidade? É uma empresinha de mil funcionários.
E esse tal de Rails? As aplicações nele usam objetos inteligentes… uma bela porcaria, não? Sisteminha besta, nada suficiente para gerenciar UM ESTADO INTEIRO.
Ah, e sabe o que mais? EJB 2.x morreram. O EJB 3 é uma revolução para que você possa exatamente ter objetos de verdade como instâncias dos componentes Java EE.
Ah, esses teóricos. Quando vão aprender?
Então você disse o quê? Eu e acredito que os outros aqui entendemos isso, pode ser que seja falta de comunicação, pode elaborar?
Cara, não estou desmerecendo seus argumentos. Quando falei que só é teoria é que, ninguém apresentou algo concreto até agora, senão eu.
Cara, vai me desculpar mais vc está vendo coisas onde não existem. Por favor, leia o as mensagens primeiro depois responda, pois assim fica difícil. Falei em PROJETOS e não UM PROJETO.
Cara, em momento algum quis dizer que alguma coisa é maior que a outra (coisa de gente sem humildade), quis explicar qual era o contexto. Se interpretou de outra forma, vê se melhora agora.
Cara, não falei que nada é ruim até agora. Conheço a ThoughtWorks, Martin Fowler e cia. Sabemos da importância do trabalho desses caras. Ah e, é um belo exemplo de empresa que coloca a teoria na prática.
É, está virando bagunça mesmo. 
Bom, falta de comunicação, atenção e acho que é melhor parar por aqui, antes que falte respeito.
Minha conclusão, mesmo que seja temporária (que contraditório conclusão temporária).
Os pacotes abaixo (mesmo que não existam [ao menos aqui])
Pacotes:
br.com.guj.dominio
br.com.guj.negocio
br.com.guj.modelo
Irão portar as classes (no domínio de forum)
Objetos:
Mensagem, Usuario, Topico e etc.
Ou seja as Entity no DDD ou Model no MDA …
A decisão sobre qual nomenclatura (Busines,Model,Domain) dar a minha “camada” pode depender da minha abordagem DDD, MDA ou meu gosto…
E no fim o que interessa mesmo é o nosso objeto forte… coeso e conciso, com responsabilidades bem definidas. (tem até padrão para definir responsabilidades GRASP)
Por exemplo, supondo que teríamos um método escrever mensagem onde o mesmo estaria: Afinal quem escreve a mensagem e o usuário, de quem é a responsabilidade? Mensagem ou Usuario?
Uma boa abordagem é que o método pertence aquele objeto que o conhece melhor, ou seja, que tem conhecimento sobre o estado do objeto.
Aqui poderia usar um service…
Usuario usr = new Usuario("dreampeppers99","senhaReal");
Mensagem msg = new Mensagem();
msg.escrever(usr);
usr.adcionarPontosPromocional();
O importante acima foi a colaboração entre os objetos(definidos com responsabilidades… mesmo que não seja a perfeita…).
Características ortogonais devem ser abstraídas. (permissão, log, transação, banco e etc…)
Não sou o melhor nem o mais indicado a ter uma visão ótima sobre modelagem oo, mas estou aprendendo. (ou no mínimo tentando.)
Obrigado à todos,
Am I rigth?
e se vc quisesse escrever varias mensagens pro mesmo usuario?
ia instanciar umonte de objetos mensagem e xamar escreve(user) varias vezes?
Ao inves disso, nao era melhor o objeto Usuario ter um List?
bah, sei lá =P
Shoes,
então seguindo a orientação a objeto não devemos separar em Produto e ProdutoBusiness.
Mesmo assim, nesse modelo, teremos características dentro de produto que não vem do mundo real, ou seja, exceptions controle de acesso ao produto, etc.
Acho que caimos então no ponto de deficiência da OO e onde entra a Orientação a Aspecto, separando os interesses de negócio dos interesses sistêmicos.
Você ve a necessidade de mais esse “filtro”, ou seja, o que você acha da aplicação da orientação a aspectos nesses casos ?
Se algo estiver errado, pf, me corrija.
[quote=fabiocsi]e se vc quisesse escrever varias mensagens pro mesmo usuario?
ia instanciar umonte de objetos mensagem e xamar escreve(user) varias vezes?
Ao inves disso, nao era melhor o objeto Usuario ter um List?
bah, sei lá =P[/quote]
Realmente não havia pensando nisto antes, foi um exemplo rápido. :lol: foi mal.
Essas questões como o negócio pode ou deve agir; essas sim são sempre discutíveis desde o contato com o cliente ao contato com o cliente (usando uma “arma” Ágil tentando estar colado no dono do produto 8) ).
Todavia sua abordagem, ao meu ver, é uma ótima visão sobre como melhorar os conceitos do Model/Domain/Business sem quebrar a orientação a objetos, ou seja, evoluir o core do sistema para facilidades.
[quote=andersonlfl]Shoes,
então seguindo a orientação a objeto não devemos separar em Produto e ProdutoBusiness.
Mesmo assim, nesse modelo, teremos características dentro de produto que não vem do mundo real, ou seja, exceptions controle de acesso ao produto, etc.
[/quote]
Infelizmente são as limitações das nossas linguagens OO de hoje. ( DSL nos dá (ou para nossos usuários) uma esperança http://fragmental.tw/research-on-dsls/ ou http://fragmental.tw/category/dsls/ )
[quote=andersonlfl]
Acho que caimos então no ponto de deficiência da OO e onde entra a Orientação a Aspecto, separando os interesses de negócio dos interesses sistêmicos.[/quote]
Isso os malditos (ou benditos) aspectos ortogonais… (sessão, log, banco, transação, …)
[quote=dreampeppers99]Minha conclusão, mesmo que seja temporária (que contraditório conclusão temporária).
(…)
A decisão sobre qual nomenclatura (Busines,Model,Domain) dar a minha “camada” pode depender da minha abordagem DDD, MDA ou meu gosto…
[/quote]
Para fins didáticos eu acho válido mas cuidado: Modelo MVC pdoe ser mais que a Camada de Negócios, pode ser controle de sessão, por exemplo.
Não entendi, você quis dizer que os pacotes são diferentes ou iguais?
Acho que você está indo por um bom caminho. no seu exemplo eu acho muito estranho uma mensagem escrever um usuário, se você passar a pensar no modelo OO utilizado por java (message-passing, nada a ver com o exemplo) vai ver que quem deveria receber a chamada ao método (a mensagem) é o usuário, já uqe uma mensagem não se escreve. De qualquer forma este ponto é mais subjetivo e mais relacionado à análise de sistemas que od esign de aplicações, é um outro ponto. Neste tópico o interessante é definirmos que um objeto tem estado e comportamento relativos à um conceito.
[quote=andersonlfl]Shoes,
então seguindo a orientação a objeto não devemos separar em Produto e ProdutoBusiness.
Mesmo assim, nesse modelo, teremos características dentro de produto que não vem do mundo real, ou seja, exceptions controle de acesso ao produto, etc.
Acho que caimos então no ponto de deficiência da OO e onde entra a Orientação a Aspecto, separando os interesses de negócio dos interesses sistêmicos.
Você ve a necessidade de mais esse “filtro”, ou seja, o que você acha da aplicação da orientação a aspectos nesses casos ?
Se algo estiver errado, pf, me corrija.[/quote]
O ponto é que você não modela o mundo real, apenas abstrações deste. Em OO geralmente voê vai modelar as operações do objeto em querstão, por exemplo quando alguém escrever uma mensagem neste fórum ele deve estar logado, se o sujeito acessa uma URI do tipo http://guj.com.br/posts/quote/30/3760322.java sem estar logado para tentar burlar é uma exceção de negócios e esta exceção deve estar mapeada no fluxo de regras de negócio.
Agora se na hora de postar o MySQL rejeitar a consulta SQL gerada este não é um problema de negócios, é de infra-esturtura. Existem algumas maneiras de resolver isso, uma delas é tratar este tipo de erro com AOP, outra é simplesmente isolar os problemas em suas Camadas (Persistência no caso) e não deixar o objeto de negócios sabendo muito sobre o que acotneceu, só que houve um erro (devidamente logado, espero).
[quote=pcalcado]
Pra fins didáticos eu acho válido mas cuidado: Modelo MVC pode ser mais que a Camada de Negócios, pode ser controle de sessão, por exemplo.[/quote]
Certo, concordo.
Iguais, meu desejo era expressar que tanto faz (o gosto ou o MDD,DDD ou XYZ) o nome que vou dar ao pacote… mas que todos podem carregar o conceito em comum.
[quote=pcalcado]
Acho que você está indo por um bom caminho. no seu exemplo eu acho muito estranho uma mensagem escrever um usuário, se você passar a pensar no modelo OO utilizado por java (message-passing, nada a ver com o exemplo) vai ver que quem deveria receber a chamada ao método (a mensagem) é o usuário, já que uma mensagem não se escreve. De qualquer forma este ponto é mais subjetivo e mais relacionado à análise de sistemas que od esign de aplicações, é um outro ponto. Neste tópico o interessante é definirmos que um objeto tem estado e comportamento relativos à um conceito.[/quote]
Certo.
Ficou meio ilégivel mesmo…
Lendo
mensagem escreve usuário
Não ficou bom… mas nem cheguei a pensar direito… (outro erro)
Numa breve discussão com paulohbmetal … (tentando uma visão oo juntamente com os bons costumes do Eric Evans)
Exemplo 1.
Service (GerenciadorConta)
(ps: exemplo tirado da apostila de oo + java da caelum)
[code]
daoFactory.getTransaction().begin();
//Núcleo envolvendo somente domínio
Conta contaA = new Conta();
Conta contaB = new Conta();
contaA.transfere(500.0,contaB);
//Fim núcleo
daoFactory.criarDao().salvar(contaA);
daoFactory.criarDao().salvar(contaB);
daoFactory.getTransaction().commit();[/code]
Exemplo 2.
Service (GerenciadorMatricula)
(ps: exemplo tirado da mente do paulohbmetal)
[code]
daoFactory.getTransaction().begin();
//Núcleo envolvendo domínio + conceitos ortogonais
Aluno aluno = new Aluno();
aluno.setNome(“ze”);
aluno.setMatricula(123456);
Turma turma = daoFactory.criarDao().getTurma(1);
turma.adicionar(aluno);
//Fim núcleo
daoFactory.criarDao().salvar(turma); //pode lançar uma exceção de negócio
daoFactory.getTransaction().commit();[/code]
São somente exemplos ilustrativos:
1 º ) Tem-se duas contas deseja-se fazer uma transferência de fundos. Transferir R$ 500,00 da contaA para contaB, no núcleo de domínio houveram as mudanças de estados (tanto em A quanto em B), logo se a transação for concluída as duas contas estarão integras e consistentes.
2º ) O segundo caso, o nosso núcleo já não está somente com domínio. Supondo que o método adiciona aluno faz uma verificação se há vagas, porém no momento em que recuperada a turma havia vagas, mas alguém foi mais rápido e adicionou um aluno a turma, continuando nossa execução quando tentar salvar a turma o Dao irá (ou terá que) gerar uma exceção (diretamente do banco ou do Dao?). Essa exceção será de negócio?
Não sei se expus exatamente a dúvida e questionamento do paulohbmetal, ele deseja saber quem irá tomar “conta” dessa regra de negócio. Não poderemos persistir essa turma já que a mesma está num estado inconsistente.
ps: poderíamos utilizar lock pessimista, todavia pensemos num ambiente onde não houve essa opção.
Não entendi muito o texto mas acho que você está perguntando se houver uma exceção quando se adiciona uma linha duplicada na tabela ela é de negócio ou não, certo?
Se for, supondo que esta regra de negócio só vá ser verificada quando se tenta inserir um registro o DAO que o faz iria receber uma SQLException dizendo que o registro foi duplicado. Supondo que você consiga identificar a causa da SQLException (o Spring é bom nisso) seu DAO pode transformá-la numa exceção de negócios:
throw new NaoHavagaException(sqlException);Que pode ser manipulada pelas classes de negócio.