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

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.

Ao meu modo de ver parece o jeito de ver algo mas de uma perspectiva diferente, estou pensando errado?

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. :smiley:

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?

[quote=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.

[/quote]

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. :wink: 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!

1 curtida

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

[quote=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".
[/quote]

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:

[quote=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. [/quote]

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!! :slight_smile:

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! :slight_smile:

A Paz!

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

[quote=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".
[/quote]

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

[quote=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.
[/quote]

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.

[quote=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.
[/quote]

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.

[quote=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. [/quote]

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

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!

[quote=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![/quote]

Um pequeno detalhe.

produto se salvar != vai para o estoque

Sao coisas bem diferentes.

]['s