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

E porque não deixar para o appserver cuidar das transações via JTA para você ao invés de cuidar de tudo na mão?

Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa “quem”.

Mas eu já cheguei a uma conclusão para minha situação, o melhor para mim seria deixar esse controle para o Business Object.

Vlw

Em quase todos os casos eu sempre usei CMT, dessa forma o container faz esse controle. Em raros casos precisei usar BMP, mas não lembro de cabeça o motivo.

Mas independente de ser CMT ou BMP o controle da transação sempre deve ficar na camada de negócio, pois é ela que sabe quando há alguma violação de alguma regra. Por exemplo, se você for incluir um usuário você precisa validar se o CPF já existe. Quem irá fazer essa verificação será sua camada de negócio (exemplo, um session-bean), então ele será responsável por saber se deverá ser feito commit ou rollback.

Se você trabalhar com session-beans notará que a transação começa no início da execução do método e termina no final da execução do mesmo. Note que se você chamar 3 métodos de EJB a partir do seu controller você terá aberto e fechado três transações.

Eu não vejo o motivo de você usar o controle de transação em outros locais. A única excessão que eu vejo é quando você está em ambientes não gerenciados o uso de artifícios como o open-session-in-view, porém isso é apenas para casos com JPA ou Hibernate.

vhmolinar:

Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa “quem”…

vhmolinar:

Pessoal boa noite,

pensando em um sistema web, na opnião de vocês em qual camada é mais correto deixar o controle de transações de banco de dados.
Na camada de Apresentação (Action) ou camada de Negócios(Business Object)?

Considerando que estou desenvolvendo um sistema web para faculdade com struts e hibernate.

ou seja

eu tenho

• ACTION - BusinessObject - DAOS

Já fiz tudo só não deleguei ainda para alguém o controle de transações, e aí alguém me da alguma dica?
Quem seria o melhor responsável para tal tarefa?

Abraços

Olá!

Como você disse que a sua transação é de Banco de Dados ela tem que logicamente iniciar e terminar no DAO. Nenhum objeto de business por exemplo, tem que saber que a transação do banco ainda esta aberta.
EX: Abre transação, salva objeto, fecha transação.

Agora, se a sua transação for de business, aí ela tem que iniciar e terminar no seu business ( Duhh! )
EX: Abre transação, remove objeto, salva novo objeto, atualiza objeto dependente, termina transação.

vhmolinar:

Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa “quem”.

Mas eu já cheguei a uma conclusão para minha situação, o melhor para mim seria deixar esse controle para o Business Object.

Vlw

deniswsrosa:

Como você disse que a sua transação é de Banco de Dados ela tem que logicamente iniciar e terminar no DAO. Nenhum objeto de business por exemplo, tem que saber que a transação do banco ainda esta aberta.
EX: Abre transação, salva objeto, fecha transação.

Agora, se a sua transação for de business, aí ela tem que iniciar e terminar no seu business ( Duhh! )
EX: Abre transação, remove objeto, salva novo objeto, atualiza objeto dependente, termina transação.

:lol: Mas hein?! Transação na DAO?!?!

Você tem uma transação que começa e termina num momento específico por causa de uma necessidade de negócio. Por isso eu acho que faz mais sentido deixar o controle de transação na camada de negócios. Dependendo do caso, faz mais sentido deixar na camada de aplicação.
De qualquer forma, a camada de infraestrutura tem operações “burras”, ele não deveria saber quais operações de alteração de dados devem ser executadas numa determinada transação.

Alguns frameworks como EJB e Spring te permitem demarcar transações na sua camada de negócios ou aplicação de uma forma transparente. Acho esse o melhor cenário. Já o pessoal do Ruby on Rails não se importa muito em deixar o código de transação no meio do código da camada de negócios…

Rubem Azenha:

…na camada de aplicação.
De qualquer forma, a camada de infraestrutura tem operações “burras”, ele não deveria saber quais operações de alteração de dados devem ser executadas numa determinada transação.

Alguns frameworks como EJB e Spring te permitem demarcar transações na sua camada de negócios ou aplicação de …

Uma camada que fica entre a camada de visualização e a camada de negócios/domínio.
Ela não contem regras de negócio nem código referente a visualização do sistema. É apenas coordena algumas atividades executada por objetos da camada de negócio.

Não é sempre que precisamos dessa camada, uma grande vantagem dela é que através dela acabamos construindo uma “API” com as regras de negócio do nosso sistema, que pode ser até exposta para outros sistemas. É um lugar interessante para se colocar o controle de transação.

O livro Domain-Driven Design do Eric Evans chama ela de Application Layer, o PoEAA do Martin Fowler chama ela de Service Layer. A descrição que eles fazem da application layer e service layer é bem parecida em vários aspectos.

Ah, vc ser refere akela imagem do ‘Layered Archterure’, c/ a definição das “conceptual layers”: UI(Presentation Layer), Application Layer, Domain Layer e Infrastructure Layer??! (não estou c/ o original do Evans, estou c/ akele DDD resumido do InfoQ; depois eu dou 1 revisada na literatura do M. Fowler.)
A propósito, citando: “Application Layer - This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.”, creio q transpondo para o nível de micro-arquitetura a ‘Application Layer’ equivale exatamente à ‘FrontController’, não concorda?!!

Rubem Azenha:

Uma camada que fica entre a camada de visualização e a camada de negócios/domínio.
Ela não contem regras de negócio nem código referente a visualização do sistema. É apenas coordena algumas atividades executada por objetos da camada de negócio…

derlon:

Ah, vc ser refere akela imagem do ‘Layered Archterure’, c/ a definição das “conceptual layers”: UI(Presentation Layer), Application Layer, Domain Layer e Infrastructure Layer??! (não estou c/ o original do Evans, estou c/ akele DDD resumido do InfoQ; depois eu dou 1 revisada na literatura do M. Fowler.)
A propósito, citando: “Application Layer - This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.”, creio q transpondo para o nível de micro-arquitetura a ‘Application Layer’ equivale exatamente à ‘FrontController’, não concorda?!!

Nao… acho que nao tem nada haver com FrontController. Acho que tem mais haver com service layer.

Eu acredito que a service layer e a application layer tem propositos parecidos, se nao identicos.

De uma olhada nessa figura, que te mostra bem claramente o que o Rubem está explicando:

http://martinfowler.com/eaaCatalog/serviceLayer.html

[]´s
Rodrigo

@rodrigo,
Estava me referindo ao ‘Service’ do DDD (resumo do InfoQ). A propósito, relendo-o acabei me deparando c/ alguma(s) ambiguidade(s) :shock:, q vou comentar no post a seguir…
(Obs.: Aki onde eu trabalho, o site do Fowler (acredite :x) é blokeado.)

rodrigo_gomes:

De uma olhada nessa figura, que te mostra bem claramente o que o Rubem está explicando:
http://martinfowler.com/eaaCatalog/serviceLayer.html

Em suma: DDD -> Application=>"a thin layer which coordinates…"; P of EAA -> Application=>APIde"Domínio"+Infra(+DB). What do u think?!!^^

<blockquote><div class="quote-author">Rubem Azenha:</div>

Nao… acho que nao tem nada haver com FrontController. Acho que tem mais haver com service layer.

</blockquote>Ah, voltando finalmente p/ falar s/ a tal ambuiguidade…

É o seguinte: Eric Evans não vê o ‘Service’ como uma “layer”. (Inclusive, procurando no texto (pelo menos no resumo da InfoQ), vc não encotra o termo “Service Layer”.)

Evans denota ‘Service’ como um tipo de Componentização de Operações de Negócio (inicialmente eu achava “de Negócio” exclusivamente) e de Operações de ‘Aplicação de Software’ (uma Aplicação enquanto Software).

:arrow: Vejamos: “The user wants to book a flights route, and asks an application service in the application layer to do so. The application tier fetches the relevant domain objects from…” -> Este “application service” percebo como sendo um (Front)Controller localizado dentro da “application layer”, a qual constumo chamar de “Aplicação Cliente” (um FrontController q atende action’s solicitadas pela request, p/ex.)

:arrow: Outra citação, esta na própria seção ‘Services’: “to transfer money from one account to another; should that function be in the sending account or the receiving account? It feels just as misplaced in either. When such a behavior is recognized in the domain, the best practice is to declare it as a Service.” Na seção anterior, ‘Entity’, Evans (muito provavelmente deve ter) reforça a importância de encapsular Operações pertinentes a uma Entidade dentro da própria Classe. No exemplo, ele busca destakar quando uma Operação/funcionalidade não pertence(é adequada) a uma Entidade ou a outra Entidade especificamente, a melhor prática é definir um ‘Service’ (uma Classe Gerenciador/Manager, p/ex.) e implentá-la nele. A minha tendencia tb é definir Fluxo de Negócio (o q tb vai de encontro ao SOA/componentização de serviços) nesta Classe|layer Service/Gerenciador. Mas, voltando ao assunto, enfim: um comportamento definido como um Service que dever ficar dentro do domain!!

Kssete, estamos indo muito off-line (mas, a discussão tá muito massa! ;-))

In brief: concluimos q o objeto ‘Service’ pode ser implementado tanto na Aplicação Cliente (como um (Front)Controller), quanto no Business-Core/API do Domain (como um ManagerService).

Todavia, considero esta abordagem/orientação muito prejudicial, pois leva à mesma confusão (principalmente por parte de Desenvolvedores principiantes), chegando até mesmo o nível de Diagramas UML, sobre Controle (o esteriótipo): se refere ao FrontController da fronteira, ou a uma Camada ‘Gerenciador’?? Considero mais salutar definir a Camada ‘Gerenciador’ (dentro da API do Domínio) como ‘Service’ (ou ManagerService) e a “Action” como um WebFrontController, até pq já existe/existia um Pattern para isto: o FrontController!

Rubem Azenha:

Eu acredito que a service layer e a application layer tem propositos parecidos, se nao identicos.

O mundo de OO é um pouco maior que o senhor Evans e o senhor Fowler.
O conceito de Serviço é o de uma classe que tem uma interface definida em separado da implementação de forma a permitir vários mecanismos tanto de negocio como de infra. O SessionBean do EJB é um serviço. O padrão “Serviço” é recente, mas a utilização é antiga ( remonta ao proprio EJB 1.1)

O limite da transação é o serviço. É por isso que serviços não são repositorios e vice-versa. Para que haja modificação do estado do sistema o fluxo deve passar por um serviço.

A camada de serviços não é uma moda, é uma necessidade. Mas existem dois tipos de serviços. O de aplicação e o de dominio.
O de dominio é transacional e provoca uma alteração no estado do sistema ou implica numa regra do dominio. O de aplicação dá suporte a serviços não-funcionais como mandar emais. Estes serviços podem ser transacionais e são chamados de serviços de dominio. Estes são serviços de suporte que podem ser usados por várias aplicações diferentes.

O senhor Evans não é a melhor referencia para nomenclatura. É dele a autoria da asneira de confundir Repositorio e DAO porque não teve o mesmo cuidado que o Fowler teve quando redefiniu o termo “value object”. O repositorio-DDD pode ser um DAO, uma lista, um qualquer coisa que se assemelhe a uma coleção. O Repositorio ( padrão Repository) inventado pelo fowler não pode ser um DAO, nem Lista, etc… e isso é explicito no padrão. O ponto é : não confie muito na nomenclatura definida pelo Evans e muito menos a generalize.

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. Até porque, como dizem os fans do DDD : “DDD não é sobre design patterns”.

sergiotaborda:

O limite da transação é o serviço. É por isso que serviços não são repositorios e vice-versa. Para que haja modificação do estado do sistema o fluxo deve passar por um serviço.
A camada de serviços não é uma moda, é uma necessidade.

sergiotaborda:

Mas existem dois tipos de serviços. O de aplicação e o de dominio.
O de dominio é transacional e provoca uma alteração no estado do sistema ou implica numa regra do dominio. O de aplicação dá suporte a serviços não-funcionais como mandar emais. Estes serviços podem ser transacionais e são chamados de serviços de dominio. Estes são serviços de suporte que podem ser usados por várias aplicações diferentes.

sergiotaborda:

O senhor Evans não é a melhor referencia para nomenclatura. É dele a autoria da asneira de confundir Repositorio e DAO porque não teve o mesmo cuidado que o Fowler teve quando redefiniu o termo “value object”. O repositorio-DDD pode ser um DAO, uma lista, um qualquer coisa que se assemelhe a uma coleção.

sergiotaborda:

O Repositorio ( padrão Repository) inventado pelo fowler não pode ser um DAO, nem Lista, etc… e isso é explicito no padrão. O ponto é : não confie muito na nomenclatura definida pelo Evans e muito menos a generalize.

(Ah, só uma Obs.: como o casal Freeman sempre fala: Os Padrões não são “inventados”, são “descobertos”!)

“repository can be closely liked to the infrastructure”

O erro é o “can”. It can not.
O repositorio não pode ter detalhes de infraestrutura.
Se tiver é uma implementação gambiarra. O padrão Repository sempre delega esses detalhes a um outro objeto.

Isso é o que deve ser. Mas não é isso que o Evans diz. Quando ele diz que “pode” significa que o repositorio pode ser o proprio dao ou o proprio entitymanager. Significa que o repositorio pode ser uma interface implementada pelo DAO. etc… o numero de aberrações possivel é imenso.
O ponto é que tudo isso são implementações erradas do padrão Repository.

O problema é que as pessoas confundem “Repository” o padrão com “repository” do DDD. Enquanto todos as implementações do padrão repository são repositorios-DDD nem todos os repositorios-DDD são implementações do padrão Repository ( por exemplo, List )

sergiotaborda:

O Repositorio ( padrão Repository) inventado pelo fowler não pode ser um DAO, nem Lista, etc… e isso é explicito no padrão. O ponto é : não confie muito na nomenclatura definida pelo Evans e muito menos a generalize.

Não. É uma conclusão que vc mesmo pode chegar estudando o trabalho de ambos. Mas leia o livro do evans não o exceto num site.

… ou camada de Negócios(Business Object)?

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.

sergiotaborda:

Até porque, como dizem os fans do DDD : “DDD não é sobre design patterns”.

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.

sergiotaborda:

…leia o livro do evans…

derlon:

… ou camada de Negócios(Business Object)?

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!

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.

sergiotaborda:

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.

É comum ver pessoas hoje dia defendendo o que vc está dizendo… mas quanto a mim isso é falta de vivencia e de entender ingles.

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.

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.

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.

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)

sergiotaborda:

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

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.

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:

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

sergiotaborda:

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.

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

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.

sergiotaborda:

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

sergiotaborda:

derlon:

… ou camada de Negócios(Business Object)?

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!

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ó.
…

sergiotaborda:

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

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.

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

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 ?