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

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

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

Pessoal,
Agora consegui visualizar o 'Service Layer'*..
Neste ponto (época) o conceito de "Domain" não estava tão amadurecido ainda (p/ menos é o q a imagem conota), pois o termo 'Domain' isolado nem sequer aparece.
Tb gostaria de deixar claro as vários tipos de Aplicações a q o Termo 'Application' pode ser referido:

Tomando o q Fowler cita "Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation." => Fowler se refere ao termo 'Application' como sendo (tudo) o q é englobado pela Service inclusive a própria ServiceLayer. Podemos concluir q esta Application (referida p/ Fowler), se refere a uma Tier (Camada Física), na qual "são centralizadas" todas as Operações de Negócio, q atualmente chamamos de Aplicação Servidora (esta contendo todas as Camadas Lógicas internas), ou Servidor de Aplicações. Um ex. disso poderia ser 1 Business-Core (+ sua Infra necessária) implementado em 1 Projeto Java, devendo este ser empacotado em um .JAR (ou .EJB, se for o caso), podendo este (Business-Core / .JAR) ser importado (incorporado) em uma 'Aplicação Cliente' Web, esta implementada em um projeto .WAR!

Já na DDD de Evans, a imagem em "Layered Architecture" a conceptual 'Application Layer' (um camada fina, como já citado), juntamente com a 'UI(Presentation Layer)' denota mais claramente o Archtetural Pattern M-V-C (apesar do termo MVC não ser mencionado explicitamente no texto..). Aqui o foco, creio eu, está no funcionamento(peculariedades) da Aplicação Cliente (na qual o o (Front)Controller deve ser uma camada "burra", q apenas "atende"(não implementa) as "ações" solicitadas, opnião compartilhada por saoj(Mentawai) ): p/ex., uma Aplicação Cliente Web em VRaptor3 redenderiza a View com JSPs/HTML e tem mecanismo próprio de dispatch (ainda q internamente use o redirect e forward da API ServletHTTP); já uma Aplicação Cliente GUI em SWING/AWT renderiza a View com JFrame/Janelas e seu macanismo de "navegabilidade" é totalmente diferente.

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

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

Rubem Azenha wrote:
Nao... acho que nao tem nada haver com FrontController. Acho que tem mais haver com service layer.

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

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

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 wrote:Eu acredito que a service layer e a application layer tem propositos parecidos, se nao identicos.

Azenha,
Tendo em vista o mencionado logo acima e no post anterior, sinto muito, mas sou obrigado a discordar de vc.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

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

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

sergiotaborda wrote: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.

Ótimas colocações!!

sergiotaborda wrote: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.

Estes "serviços de suporte": não me agrada nada chamá-los de "Serviços de aplicação".

(Sei, sou suspeito p/ falar, pois sou 1 grande fã do DDD! =P) Prefiro colocá-los num Pacote 'InfraServices' e chamá-lo de 'utilInfraSrvc', p/ex., 'mensagemInfraSrvc': para envio - usando o DIP - é transparente para o Domain se a Msg é enviada via E-Mail, ou de outra forma. (Só ficou confusa esta parte: "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.".)

sergiotaborda wrote: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.

Não consta, pelo menos no resumo do InfoQ, nada sobre o "Repository ser um DAO". Mas, volto a citar: "A Repository may contain detailed information used to access the infrastructure, but its interface should be simple." e "... the implementation of a repository can be closely liked to the infrastructure, but that the repository interface will be pure domain model." Então vemos que foram usando os verbos "may" e "can" (ou seja, "pode") e não foi usado 'must' ('deve'/deveria). Ou seja, ficou claro ele q denota 'Repository's como um tipo de Arquivo Lógico.
Vejo a coisa da seguinte forma (e até o pessoal do princípio KISS e/ou agilistas vão concordar): os Repository's podem ter um atributo 'EntityManager' (do JPA, o qual inclusive alega abstrair/encapsular a DAO) injetado por um @PersistenceContex; caso sejam percebidos "gargalos" em alguns Objetos DomainModel, seu Repository poderia então usar uma DAO, c/ abordagem JDBC puro p/ex., sendo esta DAO implementada num Pacote (totalmente) fora do Domain.

sergiotaborda wrote: 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.

Bem, isto já um questão intrerpretativa sua. Na obra de Evans, as únicas coisas q eu não gostei foram: 1. A ambiguidade, sobre Aplicação, entre o termos "software application" (Aplicação de Software, como um todo) e "application layer" (q, na minha interpretação, entendo como o FrontController); e 2. um equívoco conceitual, muito além de uma nomeclatura ambígua, de definir um 'Service' nesta dita "application layer". (O que é ainda pior.)

Mas, Q bom o Fowler ser mais assertivo/acurado. (É p/ isso q eu sou muito fã dele!

)

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

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

derlon wrote:

sergiotaborda wrote: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.

Não consta, pelo no resumo do InfoQ, nada sobre o "Repository ser um DAO". Mas, volto a citar: "A Repository may contain detailed information used to access the infrastructure, but its interface should be simple." e "... the implementation of a repository can be closely liked to the infrastructure, but that the repository interface will be pure domain model." Então vemos que foram usando os verbos "may" e "can" (ou seja, "pode") e não foi usado 'must' ('deve'/deveria). Ou seja, ficou claro ele q denota 'Repository's como um tipo de Arquivo Lógico.

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

Vejo a coisa da seguinte forma (e até o pessoal do princípio KISS e/ou agilistas vão concordar): os Repository's podem ter um atributo 'EntityManager' (do JPA, o qual inclusive alega abstrair/encapsular a DAO) injetado por um @PersistenceContex; caso sejam percebidos "gargalos" em alguns Objetos DomainModel, seu Repository poderia então usar uma DAO, c/ abordagem JDBC puro p/ex., sendo esta DAO implementada num Pacote (totalmente) fora do Domain.

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

Bem, isto já um questão intrerpretativa sua.

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.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

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

Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.!

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!

sergiotaborda wrote: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.

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'!

Enfim: considero que devemos usar o mellhor dos dois mundos!!

(@sergiotaborda, mas na definição de cada Pattern, como vc mesmo ressaltou, o Fowler é muito + preciso|acurado.)

sergiotaborda wrote:Até porque, como dizem os fans do DDD : "DDD não é sobre design patterns".

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

"Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD NÃO 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 não anêmica. 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.

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

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.

sergiotaborda wrote:..leia o livro do evans..

Quem me dera.. Sabe como a vida de Desenvolvedor (carregador de piano) começei a ler o DDD Quickly e, pela falta de tempo,..

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

derlon wrote:

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

Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.! 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)

sergiotaborda wrote: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.

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

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'!

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

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

"DDD não é sobre design patterns" -> Por um lado, eu até ampliei esta idéia (transcrito de 1 msg pvt minha):
"Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD NÃO 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.

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.

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.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

sergiotaborda wrote:

derlon wrote:[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.

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

sergiotaborda wrote: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.

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

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.

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.

sergiotaborda wrote: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.

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.

sergiotaborda wrote: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.

Excelentes colocações!!!

sergiotaborda wrote: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)

taborda, p/ ser sincero, por 1 momento, eu quase acabei concordando contigo s/ o termo "padrões de desenvolvimento"

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

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

sergiotaborda wrote:

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'!

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

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.

)

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

sergiotaborda wrote:

derlon wrote: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, vc não entedeu nada do q eu disso: vc confundiu tudo!

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

sergiotaborda wrote:
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.

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

Devemos sim sempre usar 'Layered Archteture' , mas sem BDUF - Big Design Up Front!

*

sergiotaborda wrote:uma camada nunca será um só objeto e vice-versa.

* Discordo.

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

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

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.

sergiotaborda wrote:

derlon wrote:

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

Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.! 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ó.
..

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!

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

sergiotaborda wrote:

"DDD não é sobre design patterns" -> Por um lado, eu até ampliei esta idéia (transcrito de 1 msg pvt minha):
"Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD NÃO 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.

KKKKKKKKKkkkkkkkkkkk (neste GUJ, a gente só leva "tapa na muleira", mas a gente se diverte!

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

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"

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

JavaBaby Membro desde: 29/07/2010 19:10:45 Mensagens: 76 Offline

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

JavaTeenager Membro desde: 16/05/2006 14:06:03 Mensagens: 174 Offline

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:

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:

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 ?

Notícias, artigos e o maior fórum brasileiro sobre Java