Bem objetos de domínio = negócio = modelo?

Não sou a pessoa mais indicada para falar sobre isso, mas isso pode te ajudar:

Domain Model = modelo do dominio de negocios
Domain-Driven Design = desenhar o sistema focando no modelo do dominio de negocios

:arrow: Domain Driven x Domain Model

andersonlfl essa diferença eu já “conheço” (ou acho que conheço). O problema é aplicar o que é objetos de:
negócio, domínio, modelo e entidades… isto é o que gostaria de entender, parece sempre mais do mesmo.

Fala aí Leandro(dreamspappers99) hehehehe… Tipo, eu costumo separar estes conceitos da seguinte forma, não o isolando somente a componentes:

Model
Aqui costumo classificar as classes do modelo de domínio, os conceitos complexos citados aqui pelo Raul Sidney. Exemplo -> Produto.

Business
Aqui costumo classificar as classes que validam as regras de negócio referentes as classes do Modelo de Domínio. Exemplo -> ProdutoBusiness.

Domain
Aqui costumo classificar todas as classes de um determinado domínio específico, como por exemplo na área varejista, Supermercados. Ou seja, neste caso entram tanto as classes de Regra de Negócio (Business) quando as do Modelo do Domínio (Model).

Bom, espero ter contribuído e quem sabe despertado mais discussões.

A Paz!

Paulo o seu modo de ver os conceitos é um pouco diferente do que já percebi.

Model
Business
Domain

Continuam com o mesmo conceito na minha mente. Ou seja, você não conseguiu converncer.

Eles são a mesma coisa. O Model em MVC é a parte de regras de negócio, que fica na Domain Layer. Business Layer é a mesma coisa que Domain Layer.

@paulohbmetal
Qual a diferença entre Produto e ProdutoBusiness?

dreampeppers99:

A certo tempo estou tendo contato, por meio de livros ou palestras, com vários termos do mundo da arquitetura sendo que alguns ainda não consegui ver a diferença…

Em relação a conceitos dos componentes de:
Domain
Busines
Model

Sempre que vejo esses conceitos, parece “mais do mesmo”, eles são a representação computacional de uma entidade do mundo real (com comportamento interação e estados…). Ainda existe um “padrão” Entity que parece ser igual.

Primeiro, não é o mundo da arquitetura, é do desenvolvimento. A arquitetura não depende do domínio, depende da aplicação.

Modelo (somente sem mais qualificativos) é ambiguo. Pode ser o modelo do dominio, mas pode ser o modelo de apresentação ( parte integrante do padrão MVC). Embora o modelo de apresentação dependa do modelo de dominio, eles são coisas distintas. Por exemplo, saber navegar pela aplicação faz parte do modelo de apresentação e não do modelo de dominio. Podemos ainda falar do modelo de segurança, do modelo de distribuição, etc… a palavra modelo é muito abstrata e necessidade de um adjetivo ou de um contexto explicito.

Business (negocio) é a área de atuação da aplicação. Dominio são as regras que uma aplicação segue para fornecer serviço na área de atuação. Então “venda de eletronicos” é um negocio , "sistema de vendas de electroeletronicos pela internet " é uma aplicação. Pedidos têm itens que têm produtos é uma regra do dominio.
“O cliente especial que está conosco à mais de 3 anos ganha um desconto de 20%” é uma regra de negocio.

A regras de domínio (modelo de dominio ou simplesmente dominio)e as regras de negocio (modelo de negocios ) são partes do modelo da aplicação. Entity (entidade) é um conceito existente no domínio e que têm Identidade.

Como numa aplicação o dominio e o negocio andam sempre juntos (a aplicação é limitada e não executa diferentes negocios para o mesmo dominio , por exemplo) então pode-se fundir e falar do modelo de dominio incluindo tb o de negocio. Mas num ERP, por exemplo, o dominio é só um e o negocio é configurado pelos que comprar o sistema. Ele embutem logicas de negocio próprias que são particulares a aquela empresa e que outra empresa, do mesmo ramo - do mesmo dominio , não usa.
Enfim, regras/modelo de dominio e de negocio são quase a mesma coisa, mas não bem. Normalmente não se faz a destinção quando falamos de uma aplicação de um so dominio e um so negocio.

[modo_nostalgico]
Oh, a coisa tá começando a ficar boa, como nos ‘velhos’ tempos.
[/modo_nostalgico]

E aí shoes, blz? Seguinte, como nosso colega sergiotaborda disse (em outras palavras), classifico Produto como uma Entidade do Modelo de Domínio e ProdutoBussines como a camada/classe que valida regras de negócio referentes a essa Entidade do Modelo de Domínio. Como já foi citado, teríamos regras como “O cliente especial que está conosco à mais de 3 anos ganha um desconto de 20%”… nesse tipo de camada/classe.

Bom, agora quem não entendeu o que vc quer saber fui eu. Acho que deve ser mais claro em suas dúvidas pois, como vc deve ter percebido já tem gente interpretando que o modelo que vc quer saber é o Model do MVC, e se for, a história muda um pouco pois, no Model do MVC podemos ter toda essa parafernalha que vc perguntou e muito mais. Lembrando que, quando vc fala em Model do MVC, vc pode ter vários conceitos (como também, camadas) inerentes ao mesmo.

Bom, especifique melhor o que deseja saber, pois esses conceitos (escritos dessa forma) podem soar ambíguos, como já percebeu.

Então, neste contexto que expliquei ao dreampeppers99 shoes, eu trataria isso como coisas diferentes, ou seja, em minha Business Layer eu usaria meus objetos de domínio (Domain Layer(?!)) para validar as regras de negócio. O que vc pode perceber com isso é que não trato minhas regras de negócio em minhas Entidades ou classes do Modelo de Domínio.

A Paz!

As respostas para a pergunta inicial depende do design escolhido para a aplicação. O Paulo descreveu os objetos de acordo com o design Transaction Script, enquanto Sergio e Phillip em um modelo de MDD.

Antes de entender o que é o que, Dreampeppers tem que saber que arquitetura deseja utilizar.

Não existe essa diferença entre ‘Domain’ e ‘Business’. Business Layer é apenas outro nome para Domain Layer (confira Fowler, POEAA, pg 20), mas ainda que não fosse (supondo que estmos falando de camadas realmente diferentes como Aplicação e Negócios ou Persistência) você não deveria quebrar um conceito como ‘Porduto’ entre as Camadas. O objeto produto e suas responsabilidades devem estar expressos em um objeto só e em uma Camada só, provavelmente a de Negócios. As outras Cmadas devem contêr objetos de acordo com suas responsabilidades (DAOs, gerenciadores de sessão, façades, etc.) e não pedaços de lógica do objetod e negócio (Produto).

Aí que está: você está separando regras de negócios em Camadas que não são necessárias. Regras de negócio ficam na Business/Domain Layer, mesmo que você acabe usando objetos burros (BO/VO) para representar objetos de negócio (o não é recomendado) você os deveria amntêr na mesma camada, de negócios (ou domínio).

Phillip, ao meu ver ele apenas usa nome de camada para o qual não precisava ter dado. Na pratica, ele esta usando transaction script puro (o que é uma opção, mesmo não sendo a mais indicada, de design):
"Produto(VO)" -> "ProdutoBO".

Uma classe, como a exemplificada "Produto", pode ser qualquer coisa, depende muito de todo o resto da modelagem. produto pode ser:

• Entity
• BusinessObject
• DataTransfer
• Aggregate
• NovoPatternDaEquipeDeDesenvolvimento

… depende de como as outras classes se relacionam com ela.

O que acho é que deve ser necessário firmar sobre que arquitetura estamos falando, para só então dar nomes aos bois (bois, porcos, burros, etc).

Lezinho:

Phillip, ao meu ver ele apenas usa nome de camada para o qual não precisava ter dado. Na pratica, ele esta usando transaction script puro (o que é uma opção, mesmo não sendo a mais indicada, de design):
"Produto(VO)" -> "ProdutoBO".

Minha primeira pergunta visava exatamente identificar se a situação era esta mas no meio do caminho achei algo que acredito ser mais interessante que possivelmente seria um mau uso de Camadas. Utiliza transtaction script ou domain mode não implica no imediato uso de Camadas mas se for utilizar deve-se observar alguns princípios básicos.

Uma Entity vai ser um objeto de negócios mas um objeto de negócios não precisa ser uma Entity.

yeah …

… por isso a afirmação:

Que bagunça estamos aprontando aqui… :shock:

pcalcado:

Não existe essa diferença entre ‘Domain’ e ‘Business’. Business Layer é apenas outro nome para Domain Layer (confira Fowler, POEAA, pg 20), mas ainda que não fosse (supondo que estmos falando de camadas realmente diferentes como Aplicação e Negócios ou Persistência) você não deveria quebrar um conceito como ‘Porduto’ entre as Camadas.

Mas é disso mesmo que estou falando de separação de camadas. Como já afirmei acima, não coloco minhas regras de negócio em um objeto cujo nome será Produto. Pra isso existe o ProdutoBusiness.

Uma camada só tudo bem, mas um objeto só?! Não acha que estaria agregando responsabilidade d+ fazendo uma coisa dessas? Lembremos que muitas vezes precisamos de outros e outros objetos para realizarmos nossas validações de negócio. A meu ver com essa prática o risco da classe não ficar coesa é MUITO grande. Aumenta a dependência (mesmo que com interfaces). E outra, isso me lembra os famigerados Entity Beans. argh!

Com certeza!!

Não, minhas regras de negócio ficam em uma camada só. Agora, os meus objetos de domínio (Produto, NotaFiscal, ItemNotaFiscal etc.) ficam separados. Poderiam ficar na mesma camada sem problemas, desde que as outras (Fachada/Aplicação, Persistência etc.) tivesse acesso aos mesmos.

Quando vc diz “objetos de negócio”, vc quer dizer objetos de domínio (os conceitos complexos citado pelo Raul? Ou objetos de validação de negócios? pois

Mas está ficando massa!

A Paz!

É hora do Phillip tirar fantoches da mochila e apresentar ao Paulo… heheh :twisted:

Lezinho:

Phillip, ao meu ver ele apenas usa nome de camada para o qual não precisava ter dado. Na pratica, ele esta usando transaction script puro (o que é uma opção, mesmo não sendo a mais indicada, de design):
"Produto(VO)" -> "ProdutoBO".

Bom, vamos desenhar pois, como diz um professor meu, com as ‘caxinhas’ fica mais fácil entender. Vejam a figura. O método que é chamado em minha fachada pode até ser ‘comparado’ com o ‘Transacion Script’ pois ele faz a chamada ‘sequencial’ dos métodos necessários a uma operação qualquer e delimita a transação, mas nada mais do que isso. O resto é delegado a outros objetos com suas devidas responsabilidades, conforme o diagrama. E pelo que conheço do ‘transaction script’, o mesmo é um padrão arquitetural dirigido a um procedimento único ‘faz tudo’ (interage com o banco, outros sistemas, faz validações etc.) para cada operação, o que está longe (muito longe) do que estou falando.

A Paz!

A proposta inicial da orientação a objetos é representarmos computacionalmente elementos do mundo real. Cada elemento, chamado de objeto, é representado por suas características (seus atributos) e seu comportamento (codificado em métodos).

Todo objeto, deveria portanto, ter atributos e comportamento.

A idéia de se criar objetos distintos dividindo a mesma responsabilidade quebra essa priori da orientação a objetos.

Teoricamente (e praticamente), não deveria existir Produto e ProdutoBusiness. Esta sua segunda classe é apenas uma biblioteca de funções da classe Produto… e isso não é OO.

Mas isso já tinha sido dito aqui, e vc respondeu:

Só estariamos agregando muitas responsabilidades ao objeto se o modelo de negócio assim for definido. Se “Produto” no mundo real tem “n” comportamentos, assim ele deve ser tbm em sua classe.
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.

… isso não aumenta a dependência, pq cada objeto é inteligente bastante para definir sua regra. Se for necessário de outros objetos em sua regra, é pq este “objeto a mais” deveria arquiteturalmente ter ligação com este, e isso é definição do negócio. Se ele não for na modelagem uma composição ou agregação, então tal colaboração entre as atividades dos dois podem ser definidas no service.

Mas onde que EntityBean se encaixa no que você observou?

[]s

Sua comparação com Entity beas EJB2.x foi bem oportuna. O que você está fazendo é exatamente o grande problema dos EJBs 2.x, só que usando POJOs. Você possui ‘Entity Beans’ com dados e ‘Session Beans’ com regras, um conceito como Produto está espalhado nestes dois componentes. Ao utilizar Orientação a Objetos supõe-se que você teria um objeto com a implementação completa do conceito. Ter um conceito implementado com regras de negócio separada dos dados é design procedural, não OO.

Resumindo: seu design é exatamente o utilizado em EJBs 2.x, só que com POJOs. Desta falta de entendimento sobe um design OO vieram os problemas restantes, como Camadas desnecessárias (nao há porque ter uma Camada só para ‘objetos de dados’ porque não devem existir tais objetos).

Como o Alessandro lembrou, segue um artigo sobre o tema: http://www.fragmental.com.br/bliki/index.php?title=Fantoches

paulohbmetal:

E pelo que conheço do ‘transaction script’, o mesmo é um padrão arquitetural dirigido a um procedimento único ‘faz tudo’ (interage com o banco, outros sistemas, faz validações etc.) para cada operação, o que está longe (muito longe) do que estou falando.

O TransactionScript não precisa fazer tudo sozinho, ele apenas implementa um fluxo e delega para outros objetos, que são geralmente objetos burros como os que você desenhou. As regras podem inclusive ficar em ‘sub-tarefas’ reutilizadas por todos os scripts. O ponto é que exceto em casos muito específicos utilizar Transaction Scripts não é boa idéia exatamente porque ao fazê-lo você abre mão de utilizar Orientação a Objetos no seu sistema.

Lezinho:

A proposta inicial da orientação a objetos é representarmos computacionalmente elementos do mundo real. Cada elemento, chamado de objeto, é representado por suas características (seus atributos) e seu comportamento (codificado em métodos).

Todo objeto, deveria portanto, ter atributos e comportamento.

Certo mas, pq proposta inicial?

Hum… Mas aí é que está, não estão fazendo a mesma coisa. Estou dividindo responsabilidades e isso é OO, isso é buscar reusabilidade.

Cara, sei que vc’s estão se referindo MDD, mas o que leva vc’s a defender isso como uma verdade absoluta?! Até agora não vi exemplos, existem projetos grandes feitos assim? Para grandes ficar verificável, vou exemplificar: projetos com inúmeras (+ 50 000) classes , complexas e integrações diversas entre as aplicações de um ambiente corporativo etc.

Lezinho:

Só estariamos agregando muitas responsabilidades ao objeto se o modelo de negócio assim for definido. Se “Produto” no mundo real tem “n” comportamentos, assim ele deve ser tbm em sua classe.
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.

Tudo bem, depois da resposta da pergunta que fiz acima, falamos disso.

Falei do Entity Beans pois eles agregam responsabilidades tais como ‘armazenamento e persistência’ ao mesmo tempo engessando o seu design. É aquele lance do Produto ‘se salvar’. É disso que estou falando, se estamos querendo ‘reproduzir’ o mundo real, fazendo isso estaríamos no mínimo deturpando o mesmo (mundo real). Imagina um produto com um botão: ‘Vai para o estoque.’ :lol:

A Paz!

paulohbmetal:

É disso que estou falando, se estamos querendo ‘reproduzir’ o mundo real, fazendo isso estaríamos no mínimo deturpando o mesmo (mundo real). Imagina um produto com um botão: ‘Vai para o estoque.’ :lol:

A Paz!

Um pequeno detalhe.

produto se salvar != vai para o estoque

Sao coisas bem diferentes.

]['s

fabio.patricio:

Um pequeno detalhe.

produto se salvar != vai para o estoque

Sao coisas bem diferentes.

]['s

Tudo bem, que seja, o que quiz atentar é o fato do produto ‘fazer coisas d+’, entende?

A Paz!

paulohbmetal:

fabio.patricio:

Um pequeno detalhe.

produto se salvar != vai para o estoque

Sao coisas bem diferentes.

]['s

Tudo bem, que seja, o que quiz atentar é o fato do produto ‘fazer coisas d+’, entende?

A Paz!

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.

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.

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.

fabiocsi:

Posso chamar o metodo getProdutoById direto da UI?

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!

pcalcado:

Nem isso! :shock:

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ê).

É mais meu bean é burro e não se salva.

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 ;)

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.

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

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.

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.

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/ )

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.

Isso os malditos (ou benditos) aspectos ortogonais… (sessão, log, banco, transação, …)

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…

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.

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.

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).

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.

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.

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.

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.

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();

Exemplo 2.

Service (GerenciadorMatricula)
(ps: exemplo tirado da mente do paulohbmetal)

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();

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.

dreampeppers99:

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();

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.

[/quote]

Bom, já que me colocaram na briga de volta, vou tentar expressar meu ponto de vista. Uma saída seria isolar e sincronizar o bloco concorrente para garantir a integridade, tipo:

syncronized(this) {
   Turma turma = daoFactory.criarDao().getTurma(1);
   
   if(turma.getQtdeVagas() < obtemQtdeMatriculasTurma(1)) {
      daoFactory.getTransaction().begin();

      //Núcleo envolvendo domínio + conceitos ortogonais
      Aluno aluno = new Aluno();
      aluno.setNome("ze");
      aluno.setMatricula(123456);
      turma.adicionar(aluno);
      //Fim núcleo
     daoFactory.criarDao().salvar(turma); //pode lançar uma exceção de negócio
     daoFactory.getTransaction().commit();
   } else {
      throw new NumeroDeVagasEsgotadasException();
   }
}

Então, desta forma lançaríamos uma exceção de negócios. Lembrando que temos as desvantagens do uso de tal solução, como por exemplo a perda de performance. Vale lembrar também que esse código pode ser otimizado.

A Paz!

Certo é isso mesmo, sou terrível para escrever.

pcalcado:

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:

Ahhh agora faz sentido. (depois de ler ou ter outra opinião é fácil achar sentido)

throw new NaoHavagaException(sqlException);

pcalcado:

Que pode ser manipulada pelas classes de negócio.

dreampeppers99:

pcalcado:

Que pode ser manipulada pelas classes de negócio.

Entendi, mas e se no caso acima, o erro fosse retornado a camada de Serviço, o serviço teria a responsabilidade apenas de passar-lo pra frente (seja para apresentação ou aplicação)?

Depende. Como Apresentação depende de Negócios não tem problema ela lidar com as exceções desta Camada porém você pdoe julgar ser mais útil abstrair o erro, por exemplo fazendo NaoHavagaException estender alguma ExcecaoDeNegociosException e apenas exibir a mensagem de erro.

Obrigado, apesar do tópico ter sido extenso acho que cheguei ao que queria.