Injeção de Dependência em Domain Model (ServiceLayer+DomainModel+Repository)

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

pcalcado wrote:Camadas (Layers) é um padrão sim

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.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

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.

This message was edited 2 times. Last update was at 30/10/2007 08:27:17

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

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.

This message was edited 3 times. Last update was at 18/08/2008 19:48:57

Bom, deixando suas observações pessoais de canto (pq em meu pé quem pega é a minha namorada), vamos lá:

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

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:

Domain Driven Design wrote:
"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between Services which
belong to the domain layer, and those belonging to the
infrastructure. There can also be Services in the application layer
which adds a supplementary level of complexity."

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

cmoscoso wrote:
(...) e vc se justifica colando citações sem contexto do seu autor preferido.

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.

cmoscoso wrote:
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 projeto de software OO e precisam competir com as 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.

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.

This message was edited 1 time. Last update was at 27/11/2007 09:36:38

[lugar errado]

pcalcado wrote:

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

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.

This message was edited 1 time. Last update was at 07/12/2007 08:55:01

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

Smalltalk Membro desde: 07/12/2007 11:04:42 Mensagens: 1 Offline

Talvez porque não haja.

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.

Eric Evans's excellent book Domain Driven Design has the following to say about these layers.

Application Layer [his name for Service Layer]

Domain Layer (or Model Layer)

http://martinfowler.com/bliki/AnemicDomainModel.html

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

* (Como toda regra tem uma exceção, o Manifesto Ágil partiu de uma reunião entre os autores)

PS.: Este é meu primeiro post. Espero poder contribuir e aprender muito por aqui.

pcalcado wrote:

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

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.

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

Um artigo do autor cita:

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

pcalcado wrote:

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

Um artigo do autor cita:

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

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.

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