Controle de transação - em qual camada deixar?

Programação Arquitetura
#21

[quote]… ou camada de Negócios(Business Object)?[/quote]Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.! :x Pq ela certamente provoca mal-entendidos: ela sempre leva todo mundo a pensar q é nela q devemos implementar (“centralizar” ) as Regras de Negócio, quando certo é encapsular Lógica e Regra de Negócio no própria Classe Entidade, enfim dentro dos Objetos DomainModel, né?!; afinal, não foi para isto q o Paradigma de Orientação a Objeto foi inventado (encapsular Dados (em Atributos) e Operações (comportamento em métodos)?!! Esses tais BO’s e VO’s estão começando a me dar calafrios!

[quote=sergiotaborda]Contráriamente ao que muita gente pensa a prática corrente é seguir o modelo do Fowler como indicado na figura enviada pelo Rodrigo e não o DDD.[/quote]Bem, como eu disse em outro tópico: "Claro q não podemos tomar como lei universal (e irrevogável) tudo o q os autores falam: devemos ter senso crítico."
As coisas q não me agradaram muito na imagem (modelo do Fowler) ‘Service Layer’ é: q ela não apresenta um separação clara entre Serviços de Domínio (DomainService’s) e Serviços de Infra (camada conceitual InfraEstrutura). Uhm * ela é muito curiosa: um gráfico meio tipo cebola; ah, a outra coisa q eu não achei muito legal é q ele “dá a entender” (pelo menos para os iniciantes) o q o ‘Domain Model’ deve usar a abordagem ‘Active Record’! :roll:
Enfim: considero que devemos usar o mellhor dos dois mundos!! :mrgreen: (@sergiotaborda, mas na definição de cada Pattern, como vc mesmo ressaltou, o Fowler é muito + preciso|acurado.)[quote=sergiotaborda]Até porque, como dizem os fans do DDD : “DDD não é sobre design patterns”.
[/quote]Agora indo mais off-topic ainda:
[off-topic - ***]
Meu kamarada, realmente é muito mística a tradução da palavra “design” do inglês para o português. E, por vezes ficamos injuriados quando vemos, na tradução de um livro técnico, ela traduzida para “desenhar”; então nós pensamos: q tradutor estúpido, pq ele não traduziu para Projeto|Projetar?! Afinal, p/ o pessoal da Engenharia de Software, Projeto é algo q fica entre a Análise e a Implementação.
Mas, estou começando a perceber q o significado de ‘Desing’ é um pouco mais abstrato, então podemos dizer: como vc faz o design da Análise|Modelagem; e como vc faz o desing da Arquitetura de Software; e como vc faz o design do seu Projeto; e (por que não?) como vc faz o design do seu Código (justo o q, modernamente, chamamos de factoring)?!
IMHO, alguns Patterns do GoF se encaixam mais para Modelagem do q para Projeto propriamente dito.
[/off-topic - ***]
“DDD não é sobre design patterns” -> Por um lado, eu até ampliei esta idéia (transcrito de 1 msg pvt minha):
:arrow: “Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD [color=red]NÃO[/color] tem nada a ver c/ tecnologia; é sobre o código-fonte (de nosso Software) refletir a realidade do (domínio) do negócio dos Stakeholders. E conseguimos fazer isto c/ 1 API fluente (código dos Gerenciadores c/ 1 clareza q pode ser compreendida p/ Business Experts) e com DomainModel com OO [color=red]não anêmica[/color]. E pode ser feito naturalmente em Java.” O próprio M. Fowler disse: “UML is too much, and too little.”(livre tradução: UML é tudo e nada.) Enquanto a UML fornece um ‘Vocabulário’ para um jargão comum, a Ubiquitous Languange complementa c/ ‘Gramática’ e ‘Semântica’. Uma DSL - Domain Specific Language - deve espelhar/retratar fielmente o Domínio dos Stakeholders|Usuários. E a Modelagem é o 1° passo para esta conformidade (a MDD é uma ótima opção). Mas, a UML (mesmo com uma qtd excessiva de diagramas) não é adequada para esta tarefa. Somado a isto as Languagem Workbench (dos dias atuais) estão ainda longe de conseguir traduzir esta “Modelagem” em código-fonte executável. E enquando nós do Java “ainda estamos decidindo” se continuamos ou não c/ a Rigidez Conceitual Burra, os programadores em Ruby on Rails estão correndo por fora sempre se gabando de o Ruby ser uma linguam flexível e p/ isso mais favoravel a DLS! (Perdoem-me por (ter tido q) tacar RoR nesta thread. :oops: ) Então, it’s up to us|cabe a nós (desenvolvedores Java) provar sim q é possível codificar Entity’s (Objetos de DomainModel) totalmente OO (encapsulando suas operações pertinentes) e, por conseguinte, a API de Domain com uma DLS realmente fluente (compreensível até por Analistas de Negócio|Domains Experts, etc.) :XD:
:arrow: Por outro lado, os Patterns (tanto do GoF, como da DDD, P of EAA, etc.) ajudam a assimilar os conceitos e principios do Domain-Driven Design e tb facilitam a sua adoção.

IMHO, não devemos sempre ter tanta rigidez conceitual, até pq nem todos o Sistemas precisam de tantas camadas lógicas, com tanta complexidade (ainda q a DDD não seja bala-de-prata, Ok). Porem, um Design simples o bastante (barely good enough), mas q isole o Domain (do resto da Aplicação) já propicia uma Arquitetura de Software Evolucionária|Emergente. Neste sentido, (assim como o Fowler mostra o ‘Service Layer’ como uma boundary) vejo o Repository (pelo menos numa Micro-Arquitetura inicial) como uma Fronteira, isolando o Domain da Persistência (e isto basta, se o Repositório tem links para algo de Infra: isto não é (tão) importante!). Mas, quando o Sistema crescer, em Tamanho e/ou Complexidade, aí sim justifica a adição de mais camadas (Anti-corrupção, DAO, etc.) e ai sim a Rigidez Conceitual (q deve ser adotada (apenas) neste cenário) se faz jus.

[quote=sergiotaborda]…leia o livro do evans…[/quote]Quem me dera… Sabe como a vida de Desenvolvedor (carregador de piano) começei a ler o DDD Quickly e, pela falta de tempo,… :oops:

#22

[quote=derlon][quote]… ou camada de Negócios(Business Object)?[/quote]Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.! :x Pq ela certamente provoca mal-entendidos: ela sempre leva todo mundo a pensar q é nela q devemos implementar (“centralizar” ) as Regras de Negócio, quando certo é encapsular Lógica e Regra de Negócio no própria Classe Entidade, enfim dentro dos Objetos DamainModel, né?!; afinal, não foi para isto q o Paradigma de Orientação a Objeto foi inventado (encapsular Dados (em Atributos) e Operações (comportamento em métodos)?!! Esses tais BO’s e VO’s estão começando a me dar calafrios!
[/quote]

BO (BusinessObject => Objeto de Negocios) é um padrão antigo que nada tem que ver com camada de negócios. É simples ver porque : uma camada nunca será um só objeto e vice-versa.
O BO era um padrão usado ha muito tempo atrás mas completamente descabido. Nunca foi um design pattern real, era apenas uma classe onde as pessoas misturavam responsabilidades de DAO e Serviço e seja lá mais o que for numa coisa só.

Camada de Negocios é um conjunto de serviços orquestrados a trabalharem juntos. (É o que deu origem ao SOA)

Não cabe naquele deseja essa divisão. O desenho teria que ser 3D para vermos a diferença. Se imagina que aqui são cilindros concentricos, então a diferença entre serviço de aplicação e de negocio está na profundidade, não está na distancia ao centro do cilindro do meio.

Não sei de onde tira essa conclusão. Não tem nem remota lembrança…

É comum ver pessoas hoje dia defendendo o que vc está dizendo… mas quanto a mim isso é falta de vivencia e de entender ingles. Design se traduz para desenho, quer goster, quer não.
Desenho sim é algo abstrato e muito mais criativo que arquitetura. Projeto não tem nada a ver com design, nem com software. É por isso que existem projetos de muitos tipos. Projeto é apenas conduzir atos para obedecer intensões. A tradução "padrões de projeto" é que está errada. A tradução certa é "padrões de desenho" ( em outras linguas é feita essa tradução, como em espanhol, por exemplo).

O problema de muitas equipas ( eu diria quase todas) é a falta de entender que um software nasce do design. Um bom design leva a um bom software e um mau design leva a um grande problema.

Analise e Design são opostos no sentido que Analise (dividir) significa entender o problema. Parti-lo em partes até entender o todo. Depois vem a sintese. Essa sintese é o design. É a organização das peças de software para chegar num objeto que realiza o mesmo que a ideia que analizámos. Imagine construir uma casa com peças de lego. A casa é o objetivo e o conceito. Aanlisamos como ela é formada (paredes, portas, janelas, etc…) identificamos essas peças de lego que correspondem a essa "funcionalidades" e verificamos que não existe nenhuma pessa "parede" então temos que a construir de outra peças… esta identificação e as desições que tomamos ( por exemplo, usar peças todas da mesma cor, ou usar fileiras de cor sim, cor não) são desições de design. O conceito imaginado, analisado é construir por um processo de identifiação e construção guiado pelo design. Um bom desenhista é aquele que tem conhecimento das peças que existem e de como criar novas peças com essas que tem ou, dado um conjunto limitado de peças, construir peças novas. Em software isto é ainda mais simples e desafiante porque todas as peças (objetos/classeS) podem ser construidos a partir de uma materia básica (que são os objetos principais do java ) Tudo o resto deriva dai, e a API java, por exemplo, é apenas um conjutno de peças já prontas que são tão uteis que constui-las do zero toda a vez é monotono e chato.

Design é alma do desenvolvimento, por isso muita gente traduz "design patterns" para "padrões de desenvolvimento". "Desenvolvimento" é o mais perto que temos da palavra "desenhar" sem usar a palavra "desenhar" que sempre associamos com imagem e por consequencia com GUI. (em ingles não existe essa associação já que desenhar (nom lápis) é draw)

Projetar não é o mesmo que desenhar. Projetar é limitar os recursos e mesmo assim chegar num objetivo. Desenhar é criar recuros novos com base nos que temos.

Isso, essa tecnica, que agora tem nome, é muito velha. É o proprio conceito de orientação a objetos como entidades abtratas do mundo real. Isso é OO 101 ( a primeira aula de Orientação a Objetos).
O problema é que as pessoas esquecem-se disso. DDD não trouxe nada de novo. Apenas publicitou o que já tinhamos com novos nomes. Mas , fazer o quê ? é uma moda que pegou e todo o mundo quer fazer DDD. Fazer OO bem feito é muito melhor que DDD.

Na prática não é possivel fazer isso sem usar o conceito de camada ( a comparação com a cebola não é deprositada). E historicamente identificámos 5 camadas. Repare que elas podem ser finas ou gordas o quanto vc quizer, mas elas estarão lá. É uma necessidade do conceito de dominio que não sendo um conceito abstraivel com objetos, precisa ser abstraido como um conjunto de objetos, e isso automaticamente singifica ter uma camada. Mas como só temos objetos ( tudo são objetos) é inevitável que os objetos de dominio comuniquem com outros objetos. Se isso não acontecer o dominio é inutil. E se isso acontecer, automaticamente temos que ter pelo menos uma camada mais. Este raciocinio é recursivo, portanto, se pode demonstrar um conjunto infinito de camadas. É ai que entra a prática, mas nos dizer que 5 bastam. E isso é concluido empiricamente dos dados levantados de vários softwares feitos com o mesmo proposito na mesma tecnologia.

O que eu quero dizer com tudo isto é que o conceito de camada é matemáticamente demonstrável advir do conceito de objeto + o conceito de responsabilidade e , portanto, não é algo que se possa chamar de "rigidez conceptual". As coisas são como são, e estas coisas, são assim. Quanto mais depressa entender e aceitar, mais depressa vc pode se preocupar com o que interesssa: o design.

#23

[quote=sergiotaborda][quote=derlon][off-topic - ***]
Meu kamarada, realmente é muito mística a tradução da palavra “design” do inglês para o português. E, por vezes ficamos injuriados quando vemos, na tradução de um livro técnico, ela traduzida para “desenhar”; então nós pensamos: q tradutor estúpido, pq ele não traduziu para Projeto|Projetar?! Afinal, p/ o pessoal da Engenharia de Software, Projeto é algo q fica entre a Análise e a Implementação.
[/quote]
É comum ver pessoas hoje dia defendendo o que vc está dizendo… mas quanto a mim isso é falta de vivencia e de entender ingles.[/quote]Se eu não te conhecesse (e se eu não levasse em conta o contexto em q se encontra) eu até diria q vc não tem mais argumentos o começou a levar a coisa p/ o lado pessoal. Mas… [quote=sergiotaborda]Design se traduz para desenho, quer goster, quer não.
Desenho sim é algo abstrato e muito mais criativo que arquitetura. Projeto não tem nada a ver com design, nem com software. É por isso que existem projetos de muitos tipos. Projeto é apenas conduzir atos para obedecer intensões.
Projetar não é o mesmo que desenhar. Projetar é limitar os recursos e mesmo assim chegar num objetivo. Desenhar é criar recuros novos com base nos que temos.
[/quote]…pelo visto, vc confundiu as coisas.
@taborda,
Ih, vc está confundindo ‘Gerenciar Projeto’ (o trabalho q é feito pelo Project Manager) com ‘Projetar’ (o trabalho q é feito por um Projetista). Examinemos então o exemplo do designing|projeto de 1 Automóvel novo a ser lançado: o CEO (ou Diretor de Marketing) solicita ao designer|projetista inicar o projeto(design do novo carro). O Requisito (“funcional” ): um carro Esporte, de Luxo, etc. Restrições: tamanho e dimensões do motor, sistema de suspensão, tipo de chassis; desempenho; etc.:
:arrow: Vai começar o trabalho do designer|projetista: ele tem q fazer o design do carro levando em consideração todos os Requisistos, Restrições, Estética|beleza, etc. Então quando o Projetista tiver termindado o seu trabalho, chegou a hora de construir o Protótipo deste Projeto: a Diretoria de criação pode definir alguem para conduzir e executar o Projeto de Construção do Protótipo deste Projeto.
:arrow: Vai começar o trabalho do (Project Manager|Gestor/Gerente de Projetos: este sim vai lidar com gerenciamento de pessoas (pois vai precisar de pessoas acima da média p/ construir o carro (o protótipo) q nunca foi fabricado) e gerenciar custos, pois certamente vai precisar de peças (q ainda não existem no mercado de auto-peças) q vão ter 1 alto custo. Além disso, (na maioria das vezes) ainda vai ter q ciudar para q o desenvolvimento da construção do Protótipo fique em segredo.

[quote=sergiotaborda]Analise e Design são opostos no sentido que Analise (dividir) significa entender o problema. Parti-lo em partes até entender o todo. Depois vem a sintese. Essa sintese é o design. É a organização das peças de software para chegar num objeto que realiza o mesmo que a ideia que analizámos.[/quote]O q vc chama de “Analise” modernamente é chamado de ‘Engenharia de Requisitos’ (geralmente o trabalho do Analista de Requisitos): então é “o que” o Software deve fazer. Já o vc coloca como “Design” acaba indo de encontro à Modelagem e Projeto (geralmente o trabalho do Projetista de Sistemas)): então é “como” o Software deve fazer. Então vc os coloca como sendo “opostos”. Vejamos: no Modelo das Visões 4+1 (quem gosta de UML (e RUP) deve conhecer muito bem), todas as (4) Visões devem desenvolvidas em função da Visão de ‘Caso de Uso’ e a Visão Lógica se divide em 2 níveis: de Análise e de Projeto. A modelagem da ‘em nível de Projeto’ segue o mesmo Modelo da ‘em nível de Análise’(exceto a camadas acrecidas p/ Arquitetura). Enfim, não são opostas são complementares. Mas, atualmente o Arquiteto de Software acabou “robando a cena” do Projetista de Sistemas. Se o Arquiteto é responsavel p/ definir as tecnologias, Componentes (camadas lógicas) a serem usadas no Sistema, é o Projetista de Sistemas quem deve definir como estes Componentes se relacionam entre si.

[quote=sergiotaborda]O problema de muitas equipas ( eu diria quase todas) é a falta de entender que um software nasce do design. Um bom design leva a um bom software e um mau design leva a um grande problema.
(…)
O conceito imaginado, analisado é construir por um processo de identifiação e construção guiado pelo design.Um bom desenhista é aquele que tem conhecimento das peças que existem e de como criar novas peças com essas que tem ou, dado um conjunto limitado de peças, construir peças novas. Em software isto é ainda mais simples e desafiante porque todas as peças (objetos/classeS) podem ser construidos a partir de uma materia básica (que são os objetos principais do java ) Tudo o resto deriva dai, e a API java, por exemplo, é apenas um conjutno de peças já prontas que são tão uteis que constui-las do zero toda a vez é monotono e chato.
[/quote]Excelentes colocações!!! :thumbup:

[quote=sergiotaborda]A tradução “padrões de projeto” é que está errada. A tradução certa é “padrões de desenho” ( em outras linguas é feita essa tradução, como em espanhol, por exemplo).
Design é alma do desenvolvimento, por isso muita gente traduz “design patterns” para “padrões de desenvolvimento”. “Desenvolvimento” é o mais perto que temos da palavra “desenhar” sem usar a palavra “desenhar” que sempre associamos com imagem e por consequencia com GUI. (em ingles não existe essa associação já que desenhar (nom lápis) é draw)[/quote]taborda, p/ ser sincero, por 1 momento, eu quase acabei concordando contigo s/ o termo “padrões de desenvolvimento” :lol:,porem refleti 1 pouco + e percebi q a palavra design (assim como Projetar um carro é dar sua forma) significa ‘dar um forma’. (temo ser repetitivo, mas) -> Como vai ser o design da Análise => q forma vc dar ao Modelo Funcional (Casos de Uso; UserStories; CRC cards; etc.)? Como vai ser o design do Projeto => com qual forma vc vai fazer a coesão, acoplamento, e a reusabilidade? Como vai ser o design da Implementação => com qual forma vc vai fazer a codificação (factoring)?
E tb tem aquele lance q dizem q “o q diferencia 1 Programador de 1 Desenvolvedor é q o Desenvolvedor implementa levando em consideração as boas/melhores práticas de Projeto de Sistema”. -> Então o “Desenvolvedor” seria o kara q acumula as funções de ‘Implementador de Sistemas’ e Projetista de Sistemas’. Eu só não entendo é pq vc não reconhece a importancia deste ultimo (sendo q os princípios de Projeto são coesão, baixo-acoplamento, reuso, etc.
É Taborda, tem palavras q, em determinados contextos (como, p/ex., multi theading do Java), realmente não tem tradução p/ o português; uma tradução para “Desing Patterns” poderia ser “Padrões de Design”. Na verdade a tradução certa para “Desing Patterns” é “Desing Patterns”. É isso mesmo: nem traduza. Pq simplemente não tem como encontramos 1 palavra q traduza tudo o q Design(p/ menos no contexto da Engenharia de Software) significa .

#24

[quote=sergiotaborda][quote]As coisas q não me agradaram muito na imagem (modelo do Fowler) ‘Service Layer’ é: q ela não apresenta um separação clara entre Serviços de Domínio (DomainService’s) e Serviços de Infra (camada conceitual InfraEstrutura).
[/quote]Não cabe naquele deseja essa divisão. O desenho teria que ser 3D para vermos a diferença. Se imagina que aqui são cilindros concentricos, então a diferença entre serviço de aplicação e de negocio está na profundidade, não está na distancia ao centro do cilindro do meio.

[quote]Uhm * ela é muito curiosa: um gráfico meio tipo cebola; ah, a outra coisa q eu não achei muito legal é q ele “dá a entender” (pelo menos para os iniciantes) o q o ‘Domain Model’ deve usar a abordagem ‘Active Record’! :roll:
[/quote]Não sei de onde tira essa conclusão. Não tem nem remota lembrança…
[/quote]Ah! Mas, pelo fato de imagem não ser 3D (não fica nada claro q o ‘Serviço de Infra’ deve ser Cross-cutting), acaba sendo definida em camadas concêntricas (2D) de forma q aparenta q o DomainService, para “alcançar” o Data Source, precisa necessariamente “passar” (“por dentro”) do Domain Model. Vide a imagem. :?
E tb não fica definido, de forma clara, explicita e objetiva, q os Objetos do ‘Domain Model’ (Entity’s e Value Object’s) só devem ser persistido e recuperados via Repository (Arquivo Lógico de Objetos). (A abordagem de Evans é + efetiva neste sentido. 8))

#25

[quote=sergiotaborda][quote=derlon]IMHO, não devemos sempre ter tanta rigidez conceitual, até pq nem todos o Sistemas precisam de tantas camadas lógicas, com tanta complexidade (ainda q a DDD não seja bala-de-prata, Ok). Porem, um Design simples o bastante (barely good enough), mas q isole o Domain (do resto da Aplicação) já propicia uma Arquitetura de Software Evolucionária|Emergente.
[/quote]…
O que eu quero dizer com tudo isto é que o conceito de camada é matemáticamente demonstrável advir do conceito de objeto + o conceito de responsabilidade e , portanto, não é algo que se possa chamar de “rigidez conceptual”. As coisas são como são, e estas coisas, são assim. Quanto mais depressa entender e aceitar, mais depressa vc pode se preocupar com o que interesssa: o design.[/quote]@sergiotaborda, vc não entedeu nada do q eu disso: vc confundiu tudo! :x
Eu apenas quiz dizer q: não importa se Repository tem links para algo de Infra, ou não! Se o Repositório tem uma interface q representa um ‘Arquivo Lógico de Objetos’ para o resto do Domain: já é mais do q o suficiente (pelo menos numa Micro-Arquitetura inicial)![quote=sergiotaborda]
Na prática não é possivel fazer isso sem usar o conceito de camada (…). E historicamente identificámos 5 camadas. Repare que elas podem ser finas ou gordas o quanto vc quizer, mas elas estarão lá. É uma necessidade do conceito de dominio que não sendo um conceito abstraivel com objetos, precisa ser abstraido como um conjunto de objetos, e isso automaticamente singifica ter uma camada. Mas como só temos objetos ( tudo são objetos) é inevitável que os objetos de dominio comuniquem com outros objetos. Se isso não acontecer o dominio é inutil. E se isso acontecer, automaticamente temos que ter pelo menos uma camada mais. Este raciocinio é recursivo, portanto, se pode demonstrar um conjunto infinito de camadas. É ai que entra a prática, mas nos dizer que 5 bastam. E isso é concluido empiricamente dos dados levantados de vários softwares feitos com o mesmo proposito na mesma tecnologia.[/quote]Concordo contigo. Contudo, para algumas pessoas, arquitetura em camadas não é excelencia técnica. Entretanto, ‘Layered Archteture’ é 1 das principais coisas pregadas pelo Domain-Driven Design. Mas, eu não sei o q vc tem contra o Eric Evans, pois ele orienta algo q nós concordamos (embora isto ainda não seja 1 consenso universal). :shock:
Devemos sim sempre usar ‘Layered Archteture’ , mas sem BDUF - Big Design Up Front! :hunf:
[quote=sergiotaborda]uma camada nunca será um só objeto e vice-versa.[/quote] Discordo. :thumbdown: Vc foi infeliz ao usar o termo “nunca”. Uma Camada Lógica sim pode ser implementada por 1 Objeto!
Se vc usa VRaptor3 a Camada FrontController é representada unicamente por 1 Classe Controller. A Camada DAO é 1 Objeto de Acesso a Dados. A Camada Repositório pode ser implementada unicamente por 1 Classe Repository (para cada Caso de Uso ou Entidade) ainda q esta classe seja herdada de uma Classe Abstrata/Genérica; e assim vai…

[quote=sergiotaborda]Camada de Negocios é um conjunto de serviços orquestrados a trabalharem juntos. (É o que deu origem ao SOA)
[/quote]Nada disso!
O q deu origem ao SOA foi: a iniciativa de Componentizar Fluxo e Lógica (esta devendo ser implementada dentro da Entidade) de Negócio na forma de Serviços|Services e expô-los de acordo como contexto/necessidade desta forma.

[quote=sergiotaborda][quote=derlon][quote]… ou camada de Negócios(Business Object)?[/quote]Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.! :x Pq ela certamente provoca mal-entendidos: ela sempre leva todo mundo a pensar q é nela q devemos implementar (“centralizar” ) as Regras de Negócio, quando certo é encapsular Lógica e Regra de Negócio no própria Classe Entidade, enfim dentro dos Objetos DomainModel, né?!; afinal, não foi para isto q o Paradigma de Orientação a Objeto foi inventado (encapsular Dados (em Atributos) e Operações (comportamento em métodos)?!! Esses tais BO’s e VO’s estão começando a me dar calafrios!
[/quote]BO (BusinessObject => Objeto de Negocios) é um padrão antigo que nada tem que ver com camada de negócios. É simples ver porque : …
O BO era um padrão usado ha muito tempo atrás mas completamente descabido. Nunca foi um design pattern real, era apenas uma classe onde as pessoas misturavam responsabilidades de DAO e Serviço e seja lá mais o que for numa coisa só.
…[/quote]Se BO é 1 padrão velho (e “completamente descabido”), não é + util atualmente e ainda por cima é prejudicial, então ele deve ser considerado 1 ‘Anti Padrão’ nos dias atuais! :expressionless:
E além disso, o termo Business Object (Objeto de Negócio) é muito ambíguo, pois algumas pessoa usam ele para se referir à Entidade de Negócio e outras já usam para se referir a 1 tipo de Classe Gerenciadora ou o próprio ‘Serviço de Domínio’(DomainService). Os Padrões da DDD são muito + claros e objetivos, evitando confusão e mal-entendindos como estes, p/ex. =D

[quote=sergiotaborda][quote]“DDD não é sobre design patterns” -> Por um lado, eu até ampliei esta idéia (transcrito de 1 msg pvt minha):
:arrow: "Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD [color=red]NÃO[/color] tem nada a ver c/ tecnologia; é sobre o código-fonte (de nosso Software) refletir a realidade do (domínio) do negócio dos Stakeholders.
[/quote]Isso, essa tecnica, que agora tem nome, é muito velha. É o proprio conceito de orientação a objetos como entidades abtratas do mundo real. Isso é OO 101 ( a primeira aula de Orientação a Objetos).
O problema é que as pessoas esquecem-se disso. DDD não trouxe nada de novo. Apenas publicitou o que já tinhamos com novos nomes. Mas , fazer o quê ? é uma moda que pegou e todo o mundo quer fazer DDD. Fazer OO bem feito é muito melhor que DDD.[/quote]KKKKKKKKKkkkkkkkkkkk (neste GUJ, a gente só leva “tapa na muleira”, mas a gente se diverte! :lol: ) Karamba, desta vez vc até pegou leve e não quis esculhambar com “o ABC da” Orientação a Objetos (ou o A E I O U da OO =P)
Ninguem aki falou q a DDD usa técnicas novas (e repito o q os Freeman sempre falam: Os Padrões não são “inventados”, são “descobertos”!) Mas, como já mencionei, o q é mais importante na DDD (q em conjunto com Agil, forma 1 Killer Approach) é a Ubiquitous Languange buscando um maior envolvimento dos Usuários para se obter 1 DSL o mais Fluente possível. E outra coisa: ninguem é obrigado a usar logo de cara todas as técnicas e padrões da DDD =>(isto por si só já é fazer ‘bdup’, algo como os insípidos queriam adotar RUP fazendo todas as suas Atividade e Artefatos “de cabo-a-rabo” e, ainda p/ cima, seguindo ciclo de vida Cascata) :shock:
O problema é q, se as pessoas alegam conhecer|dominar (as tecnicas OO) Encapsulamento, então pq nunca poem em prática?!! O q temos é o “ranço” da famigerada abordagem Struts1.x+EJB2.1-, na qual tinham-se JSP(c/ TabLibs Struts)+FormBean+Action+BO+VO+EntityEJB+DAO (q, diga-se de passagem, é o único Padrão “q se aproveita” :shock: ) Então “eles” sakaram q o EJB2 erá 1 engodo (e se livraram dele | o EntityEJB sai de cena!), os Programadores “da nova geração” acharam então q as ‘Entidades de Negócio’ deveriam se (ser sufixadas com) chamar (te dou 1 doce, adivinha o q (doi até o meu ouvido)): VO; e o resto da história todo mundo sabe. Infelizmente todo o mal começou aí. Me fala 1 FrameWork + invasivo|intrusivo q a API do EJB!?!
E por causa disso, a maior parte dos desenvolvedores Java, a partir de então deixou de fazer um Encapsulamento minimamente descente(evitando o ‘Anti Pattern’ JavaBean), um ótimo “Hidding of Information” e não expor a estrutura interna de suas Classes
@sergiotaborda, (se vc considera o DDD “um mau”)da mesma forma q vc mesmo disse q os “serviços não é uma moda, é uma necessidade.”, pelos motivos apresentados, o DDD tb não é uma moda, é (“um mau necessário”) uma necessidade.
Bem, já me dou satisfeito c/ a discussão, vou parando p/ aki… Mas, quem quiser nos acompanhar (todos v6 (não só o Taborda) numa tb excelente discussão em (tópico “Problema com dependencia lazy.”) em http://www.guj.com.br/posts/list/15/209155.java#1067998 são muito bem-vindos!!! :wink:

#26

Utilizamos o padrão WorkUnit descrito pelo martin fowler. Assim, a aplicação nunca cria transações de BD e sim transações de negócio. Quando fazemos um commit do workunit, ele faz mais ou menos o seguinte:

try {
abre transacao com o banco
atualiza tudo
commit
}
catch … {
rollback
}
finally {
fecha transação
}

Abraços

#27

ok vou ser bem direto ! Em meus sistemas java meu controle de transações fica na camada de negócios. Basicamente eu tenho view->business->dao->db . Uso spring para gerenciá-la, logo fica algo do tipo:

no spring:


<!-- this bean will be transactional... -->
	<bean id="appService" class="br.ufu.portalAluno.business.impl.ApplicationServiceImpl" />

em minha abstract action, a qual as actions herdam, tenho o atributo de classe appService e seu setter, logicamente através de sua interface. Nessa classe ApplicationServiceImpl tenho a seguinte configuração:



@Transactional
public class ApplicationServiceImpl implements IApplicationService {
	private ICursoDAO cursoDao = null;
         ....

        setters...

       ... 
       @Override
	public void searchProcessingMatriculationAdjustsTotalRecords(UserSettings userSettings, String appParamName ,String appParamsItemPeriod) throws PortalDAOException {
		cursoDao.searchProcessingMatriculationAdjustsTotalRecords(userSettings,appParamName,appParamsItemPeriod);
		
	}

pronto. O controle de transações está nas mãos do spring. Eu nao mostrei um insert ai mas se falhar um insert chamando no dao em um loop ai dentro de um método, haverá um rollback no banco automaticamente.

Simples não ?

#28