Eu quis dizer que fowler não define Service Layer como um padrão de domain model (ou um “building block” como Evans define seus padrões)
Services de DDD pertencem ao domínio do problema e por isso podem existir entities que dependam de tais Services.
Aiaiai …
Services são Services. Existem de aplicação e de negócio, não sei onde esta a complicação disso. Tanto o DDD quanto o PoEAA comentam dos dois.
De fato Phillip, a discussão era de Manga e já estamos falando de Banana.
[quote=Lezinho]Aiaiai …
Services são Services. Existem de aplicação e de negócio, não sei onde esta a complicação disso. Tanto o DDD quanto o PoEAA comentam dos dois.
De fato Phillip, a discussão era de Manga e já estamos falando de Banana.[/quote]
Desnecessário seus gemidos… Inclusive, é lamentável a atitude de desdém das pessoas quando questionadas quanto a sua interpretação sobre os textos mencionados.
Você não percebe mas a complicação está no fato de você não conseguir explicar com clareza a diferença entre a camada Service e Application. Talvez porque não haja. Você cita duas fontes que definem a mesma coisa com 2 nomes, reconhecidamente um conflito na nomenclatura atual senão, vamos lá, precisamos ter claro as responsabilidades de cada camada, mas esse não parece ser o caso, pelo contraráio, você parece ignorar princípios importantes como YAGNI e KISS e se justifica colando citações sem contexto do seu autor preferido.
Talvez o tamanho dessa thread tenha feito você perder o foco mas eu vou tentar ser ainda mais claro:
Eu considero as camadas Service e Application como a mesma e não sinto falta de outra camada.
Pense que existem pessoas que estão interessadas em comecar a aplicar práticas mais modernas para o seu projeto de software OO e precisam competir com as tais arquiteturas de “referência” estabelecidas. Eu não vejo como essa camada adicional pode ajudar essas pessoas a melhor organizar sua arquitetura usando apenas o seu argumento de que tem que ser assim porque o mestre mandou.
Bom, deixando suas observações pessoais de canto (pq em meu pé quem pega é a minha namorada), vamos lá:
Talvez VOCÊ não percebeu que não sou eu que menciona sobre as diferenças, mas sim os próprios autores, como no texto que citei no post anterior. Aliás vale repetir a citação:
… pra mim esta bem clara e nítida a existência entre Services de infraestrutura, pertencentes a camada de aplicação, e os services pertencentes a camada de domínio, aqueles que se relacionam com um caso de uso. Detalhe, o trecho acima trata de Services no capítulo destinado a Services em um livro de DDD, portanto são Services do DDD. Não há falta de contextualização.
Com base no trecho acima, olhe no diagrama de classe que Fowler colocou no PoEAA (a qualidade ficou péssima, mas acho que você vai conseguir visualizar as classes), que esta anexada com este post. Lá esta descrito um modelo exatamente como na citação, um service para o negócio e um para a infraestrutura da aplicação.
[quote=cmoscoso]
(…) e vc se justifica colando citações sem contexto do seu autor preferido.[/quote]
Fora do contexto? São trechos totalmente pertinentes a suas colocações, vindas de autores como Martin Fowler, Eric Vans, Floyd Marinescu… Se estas pessoas não são boas referências, então realmente estou mal embasado.
Se você não sente falta, não utiliza. Nenhum destes autores citados dizem que você DEVE usar um Service voltado para os serviços de aplicação, ou um como ponte para os objetos de domínio. Você usa conforme sua necessidade. Toda camada é “adicional”, você usa se sente necessidade de usá-la.
[lugar errado]
[quote=pcalcado]
Só é bom focarmos que discordar é ótimo. Eu discordo do Fowler bastante em DSLs, por exemplo. O ponto é ter um mínimo de respeito pelos outros e darmos base às nossas discordâncias, seja usando uma bibliografia ou argumentando. …[/quote]
Eu coleciono essas discordâncias com autores famosos… não dá pra concordar com tudo. Eu discordo com a visão do Philipe Krunchten sobre Análise e Design. Discordo com a visão do Ambler sobre MDA. Discordo com a visão do Ivar Yacobson sobre as maravilhas de um Use Case ser um Classifier.
Lezinho, vc tem algum paper sobre essas regras de segurança com o Drools? (creio que vc tenha aplicado isso na sua aplicação SEAM).
Eu estive com o Krunchten num workshop do SPIN em porto alegre e pesar da fantastca sacada dos pontos de vsta arquiteturais eu discordo bastante dele tambem. Ele nsiste em BDUF sem parar muito para debater.
Aspecto só dever ser utilizado para tratar dos interesses transversais ou sistemicos e não na sua lógica de negócio.
Por que?
Uma regra de negócio ode se comportar como aspecto, validações são um exemplo.
Injetar um repositorio ou um service numa entidade é um interesse transversal. Mesmo que não fosse, se uma determinada regra de negócio fosse melhor implemetada com aspectos, na minha opinião, não teria problemas. Desde que exista boas razões para tal.
Acho que a confusão este caso é o que é regra de negócio. Um Domain Model contem regras de negócio mas provavelmente não é o único lugar onde estas ficam. Dificilmente as relações dentro de um domain model seria tratadas com aspectos mas as outras regras isoladas poderiam.
E realmente não há. 
O proprio Fowler explica em um post no seu bliki, esta confusão (normal) sobre a salada de termos que os autores criam.
Vejam que ele precisa explicar isso, porque esta falta de entendimento que causa o “Anemic Domain Model”. Vejam: é normal existir esta confusão.
E a explicação pra isso é a mais clara possível: pessoas agem e pensam de formas diferentes. E dão “nome aos bois” de formas diferentes. E autores são pessoas!
Estas pessoas (Fowler, Evans, Booch, Rockford Lotha, etc…) tem idéias/soluções e as publicam em formas de livros e artigos. E sempre encontram os que concordam e discordam.
Eles não formam um grupo para debater e formalizar estas idéias/soluções e nomes. E mesmo assim elas são compartilhadas.
Estas idéias/soluções existem para nos ajudar, “iluminar nosso caminho”, mas normalmente cada uma delas foi concebida em um “caminho” distinto. Não devemos tomar como verdade ou como padrão o que um ou outro autor apresenta sem definir o contexto, o caminho que nós estamos pisando.
A propósito, a diferença entre uma solução e uma idéia seria um bom assunto pra outro post. Normalmente soluções nos ajudam na prática, e idéias quebram paradigmas, ajudam a vender livros e palestras, mas não há garantia de que vão resolver um problema e ainda deixam a cabeça dos arquitetos pegando fogo! (DSL?).
PS.: Este é meu primeiro post. Espero poder contribuir e aprender muito por aqui.
Por que?
Uma regra de negócio ode se comportar como aspecto, validações são um exemplo.[/quote]
Aspecto é um assunto bastante interessante, e um bom livro sobre aspecto é Aspectj Programação Orientada a Aspectos com Java, editora Novatec. O aspecto veio para ajudar onde a OO falha, separar os interesses funcionais dos interesses sistêmicos.
“A incapacidade da OO de modularizar os interesses sistêmicos ocasiona os problemas resultantes da descentralização do código:
.Replicação do código;
.Dificuldade de manutenção;
.Redução da capacidade de reutilização de código;
.Aumento da dificuldade de compreensão;” (Diogo Vinícius Winck e Vicente Goetten Jr)
Entenda funcional como sua lógica de negócios e sistêmicos o restante como exceções.
Você não me respondeu. Porque eu não posso tratar minhas regras de negócos como aspectos?
Eu não li este livro mas acredito que possa ter passado alguma confusão. AOP diz como implementar os conceitos mas não diz quais são (tanto que os exemplos sempre recaem nos mesmos de sempre: log, segurança, transação), regras de negócio podem ser implementadas como conceitos ortogonais se for interessante. Um exemplo que já citei é validação, outro é segurança. Ambos geralmente são regras de negócio e não uma necessidade não-funcional (o que você chamou de ‘sistemico’). Recomendo que leia o livro de Ramnivas Laddad , AspecJ in Action. Não sei se tem em português.
[quote]At the system level, security, transaction management, and thread-safety concerns are commonly implemented using AOP. Many business logic problems (also known as domain-specific concerns) also exhibit crosscutting concerns upon close examination and lend themselves to modularization using aspects. On the other side, units such as classes and packages show code tangling and code scattering at a smaller scale (what I call local or micro crosscutting concerns). Aspect-oriented refactoring can help resolve these kinds of concerns by using aspects to improve the code structure. (See Resources to learn more about aspect-oriented refactoring techniques.)
[/quote]
[quote=pcalcado][quote=Cobracan]
Aspecto é um assunto bastante interessante, e um bom livro sobre aspecto é Aspectj Programação Orientada a Aspectos com Java, editora Novatec. O aspecto veio para ajudar onde a OO falha, separar os interesses funcionais dos interesses sistêmicos.
“A incapacidade da OO de modularizar os interesses sistêmicos ocasiona os problemas resultantes da descentralização do código:
.Replicação do código;
.Dificuldade de manutenção;
.Redução da capacidade de reutilização de código;
.Aumento da dificuldade de compreensão;” (Diogo Vinícius Winck e Vicente Goetten Jr)
Entenda funcional como sua lógica de negócios e sistêmicos o restante como exceções.
[/quote]
Você não me respondeu. Porque eu não posso tratar minhas regras de negócos como aspectos?
Eu não li este livro mas acredito que possa ter passado alguma confusão. AOP diz como implementar os conceitos mas não diz quais são (tanto que os exemplos sempre recaem nos mesmos de sempre: log, segurança, transação), regras de negócio podem ser implementadas como conceitos ortogonais se for interessante. Um exemplo que já citei é validação, outro é segurança. Ambos geralmente são regras de negócio e não uma necessidade não-funcional (o que você chamou de ‘sistemico’). Recomendo que leia o livro de Ramnivas Laddad , AspecJ in Action. Não sei se tem em português.
[quote]At the system level, security, transaction management, and thread-safety concerns are commonly implemented using AOP. Many business logic problems (also known as domain-specific concerns) also exhibit crosscutting concerns upon close examination and lend themselves to modularization using aspects. On the other side, units such as classes and packages show code tangling and code scattering at a smaller scale (what I call local or micro crosscutting concerns). Aspect-oriented refactoring can help resolve these kinds of concerns by using aspects to improve the code structure. (See Resources to learn more about aspect-oriented refactoring techniques.)
[/quote]
[/quote]
A questão em sí é que aspecto veio para completar a OO, onde a OO falha ou deixa a desejar. Você pode usar aspectos para sua lógica de negócio mas me parece muito estranho um SOO usar aspecto em sua camada de negócios e particularmente tenho minhas dúvidas. Esse assunto é muito interessante e polêmico. Não sou um especialista para afirmar o que deve ser ou não, mas a minha opinião é que devemos separar as responsabilidades.
IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.
Acho aspectos muito bem vindo quando o assunto é injeção de dependências. Um bom exemplo é o @Configurable do spring, ou melhor ainda, inventar uma macumba para seu domain não depender de container de DI nenhum, e isso é possível com AOP.
[quote=Thiago Senna]IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.
[/quote]
Thiago, Specfication não serve para isso. Specification serve para verificar s um objeto é condizente com um dado critério, não se ele é válido. Você não precisaria de uma spec ara dizer se um triângulo de dois vértices é válido, o objeto deve se verificar. Como todos nós sabemos um problema deste tipo de coisa é que validação geralmente resulta em código duplicado porque você ode querer verificar isso em outros lugares antes de formar o objeto em si.
[quote=pcalcado]
Thiago, Specfication não serve para isso. Specification serve para verificar s um objeto é condizente com um dado critério, não se ele é válido. Você não precisaria de uma spec ara dizer se um triângulo de dois vértices é válido, o objeto deve se verificar. Como todos nós sabemos um problema deste tipo de coisa é que validação geralmente resulta em código duplicado porque você ode querer verificar isso em outros lugares antes de formar o objeto em si.[/quote]
Hmmm… Vc ta falando de validações basicas, tipo aquelas comum em construtores de VOs que procuram por nulls e illegal exceptions. Acho que seria uma boa mesmo, nem que seja posteriormente com o modelo numa situacao mais estavel com relação a refactoring.
VOs? COmo assim?
[quote=Thiago Senna]IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.
[/quote]
Sim, o Specification é o padrão para validação, mas AOP pode ser util para manter a consistencia sem grande trabalho. Em vez de vc escrever aquele código chato que verifica se os paramentos são null ou fora de range vc pode simplesmente anotar e deixar alguem fazer o trabalho. Ok, isto é feitos com alguns frameworks de anotations que usam algo anterior ao AOP : bytecode rewrite. Afinal é a capacidade que o java tem de poder alterar o bytecode em runtime que habilite as ferramentas AOP que são apenas uma forma de implementar inceptações do codigo normal. As implementações de AOP são apenas um frameowrk simples de bytecode rewrite. Existem outras formas de bytecode rewrite que alcançam os mesmo objetivos. No fim, tlv seja mais facil usar um framework baseado em anotations para fazer a consistencia dos objetos do que escrever uma monte de cutting concerns repetidos.
[quote]
Acho aspectos muito bem vindo quando o assunto é injeção de dependências. Um bom exemplo é o @Configurable do spring, ou melhor ainda, inventar uma macumba para seu domain não depender de container de DI nenhum, e isso é possível com AOP.[/quote]
A injeção é feita pelo mesmo mecanismo de bytecode rewrite. Os frameworks que fazem isso não usam AOP.
E se vc for escrever o seu proprio DI container tb não vai usar AOP. Porque AOP é baseado em bytecode rewrite, então é muito mais eficaz usar bytecode rewrite logo de base.
AOP é bytecode rewrite para regras genericas que os frameworks de butecode não podem antever.E por isso são ideiais para injetar regras de aplicação (log, transação, etc)
