Bom dia povo do GUJ.
Antes de mais nada gostaria de informar q estou lendo esses links:
http://www.guj.com.br/posts/list/129676.java
http://www.rponte.com.br/2009/06/08/no-more-daos/
http://www.infoq.com/articles/ddd-in-practice
http://infoblogs.com.br/view.action?contentId=36202&DomainDriven-Design-e-Simples-Basta-Chamar-DAOs-de-Repositorios.html
http://arquiteturadotnet.wordpress.com/2010/05/12/camadas-de-aplicacao-e-dominio-no-ddd/
Que sao materias q achei pertinente ao assunto.
Seguindo.
Desenvolvi um sistema a uns 2 anos atras, quando estudava um pouco sobre DDD. Tentei aplicar alguns conceitos talvez nao tenha ficado otimo, mas acho q esta no caminho.
Acabamos motando a seguinte arquitetura:
O Sistema era relativamente simples, sem muitas regras de negocio.
Agora estamos iniciando um novo, que terá N processos de negócio, N formas de acesso e afins.
Gostaria de saber de vcs, oq recomendariam que fosse alterado e pq, baseado em suas experiencias de desenvolvimento.
A intencao eh simplificar o codigo, nao pretendemos usar Spring.
Sera um sitema Java, com clientes Web-Flex, Delphi, Mobile e derrepente ate TV Digital(pq nao 
).
Continuo lendo os links q postei acima para ver oq pode ser melhorado nesse modelo que postei.
Conto com a colaboração de vcs.
Grande abraço.
Feltraco,
Na minha opinião acho que você está no caminho certo.
Eu acredito que é bem importante você definir bem os tipos de comportamento e estado que cada camada que a sua aplicação deve ter.
Além do diagrama de classes você poderia criar um texto descritivo de cada camada e que tipo de tarefas ela deve desempenhar ou conter.
Eu estou trabalhando em um modelo de camadas baseado no DDD que eu resumo da seguinte forma:
- Presentation (Interface com Usuario (MVC) / Comportamentos e estados referentes a interface)
- Application (Services, Factorys / Comportamento complexos da aplicação invocados pela interface)
- Domain (ValueObjects, Entidades, Agregates / Comportamentos/estados relacionados a minhas entidades)
- Integration (GenericDao / Implementacoes de Repositories especificos)
Alguns pontos:
Eu não crio portas de entrada de cada camada, no Modelo do meu MVC eu posso algumas vezes estar invocando um Service, outras vezes estar criando uma entidade do domínio para utilizar seu comportamento ou resgatando dados de alguma fonte de dados através de um Repository.
Independentemente da camada eu sempre mapeio os dados para Entidades/ValueObjects do meu domínio, e evito ao máximo a replicação de comportamento entre as minhas classes.
Lembrando, eu trato aqui value objects como objetos de valor mesmo(CPF por exemplo), normalmente imutáveis e com valores e siginificados bem específicos.
Como vc espera sugestões de alteração na sua arquitetura sem nos contar o que seu sistema faz, ou deveria fazer???
Sera um sistema com vários módulos.
Gerenciamento de estoque, emissão de CT-e (tipo NFe), Modulo administrativo geral e por filial, dentre outros.
Tera clientes WEB, Desktop e Mobile.
Gostaria de sugestoes principalmente quanto a camada Service desse modelo.
Ela recebia todas as requisicoes vindas da WEB, no novo modelo terei clientes Desktop e Mobile, certamente com validações e controles diferentes.
Humm…
Por que vcs não pretendem utilizar Spring?
flws
Pela curva de aprendizado.
Tenho uma noção de Spring, mas para utilizar em um sistema desse porte eu teria que fazer um curso ou contratar alguem que possual tal conhecimento.
Entendi.
Porem, pelo que vc disse sobre seu projeto, ele seria de emensa ajuda. Iria fazer você ganhar muito tempo em desenvolvimento. Tem bastante material na net explicando seu funcionamento inclusive livros em protuguês. Tente reconsiderar.
Fora isso no diagrama que vc publicou você apontou alguma coisa sobre email e report associado a DAO / Repositorio. Talvez fosse melhor colocar isto nos serviços. Na literatura do Martin fowller ele fala sobre gateway talvez ficasse ainda melhor se considerasse essa idéia.
Faça uma leitura novamente sobre Repositorios para concluir se realmente você precisa de DAOs, normalmente Repositorios associados com o ORM já são suficientes.
Espero ter ajudado.
flws
Entao fantomas, essa questao de Dao e Repository vi que dah muito pano pra manga.
Tb vi que nao tenho a necessidade de Criar N DAOs, prentendo fazer um genérico e criar implementações somente quando for extritamente necessário.
Não sei se é isso que vc quis dizer.
De qq forma, continuo lendo sobre o assunto, agora vou dar uma pesquisada sobre Gateway na literatura do Fowler.
Ate+
@PedroTOliveira
Entao cara, tentei seguir este modelo tb.
Minhas duvidas agora comparando com oq vc propos sao referentes a Presentation, onde vou ter algumas formas diferentes de interface e na Integration, com relacao a Dao ou Repository Generico e tal, que pelo q eu li eh o mais recomendado.
[]'s
Estes mesmos, principalmente o Spring em Ação.
O ideal é que você leia e vá colacando em pratica ao mesmo tempo para criar motivação. Como o Spring não envolve nada visual a leitura do material pode se tornar bem chata. Tente utilizar um projeto já existente.
No seu caso eu diria que os principais pontos do spring seriam: transações, serviços, acesso a dados (data source, orm). Depois você ataca outros módulo que julgar interessantes para o seu projeto.
flws
Opa Feltraco,
Poderia explicar melhor as suas dúvidas com relação a camada de apresentação e integração?
[]´s
Claro…
Na apresentacao, uma das dúvidas que ainda ficam eh a seguinte.
No sistema que tenho em producao, soh havia um tipo de acesso ao sistema, entao minha camada service era a porta de entrada da aplicação. Gerenciava os Entitys e os Daos, startando transacoes e afins.
Como agor terei outras formas de acesso, penso se terei q criar uma camada de apresentacao para cada tipo de acesso, para fazer suas respectivas validações e então chamar a “service” para iniciar os processos de negócio.
Na integração, anteriormente tinha um DAO pra cada UC. Já li bastante sobre repository e na época tentei usar alguns conceitos mas acho q nao ficou muito bom :P. Agora penso em fazer um genérico e implementar funcções somente quando necessário. Acho q chega mais perto do conceito.
[]'s
Então, a ideia é você realmente não ter portas específicas de entradas para a sua API de negócios.
Se você pensar que suas camadas Application e Domain servirão as outras camadas através de suas interfaces e se suas interfaces possuírem contratos(comportamentos) bem definidos a suas outras camadas utilizarão os comportamentos pertinentes a aquela operação.
Claro que na sua camada de apresentação utilizando um modelo MVC na classe que aplica a ligação com o modelo você estará de alguma forma chamando essa sua API de negócio.
Eu montei um modelo rápido de camadas baseado no seu exemplo para tentar ajudar a sua visualização.
Ressuscitando o topico!!!
@Fantomas
Vc poderia me dar um exemplo de uma implementacao sua de Repositorios associados com o ORM.
@PedroTOliveira
Defino a camada de “entrada” no sistema, pois eh a classe q eu mapeio para virar um “servico” no FLEX.
Classe essa q tb jah gerencia a transacao caso exista.
PS: Andei lendo mais ainda sobre o Spring, aqueles XML estao me desmotivando a utiliza-lo 
[quote=feltraco]Ressuscitando o topico!!!
@Fantomas
Vc poderia me dar um exemplo de uma implementacao sua de Repositorios associados com o ORM.
@PedroTOliveira
Defino a camada de “entrada” no sistema, pois eh a classe q eu mapeio para virar um “servico” no FLEX.
Classe essa q tb jah gerencia a transacao caso exista.
PS: Andei lendo mais ainda sobre o Spring, aqueles XML estao me desmotivando a utiliza-lo :([/quote]
Ah sim, pode ser, Nesse modelo ai que montei eu colocaria esse “servico” na camada Application.
Outro ponto, eu coloquei a Interface do repository na Application, mas acredito que ela deveria estar na camada Domain.
Pergunta: Você externaliza o serviço via Web Service?
Na vdd nao comecei a desenvolver ainda.
Mas se trantando de FLEX, nao sao WS nao, eh via AMF consumindo diretamente os metodos na AplicationService.
Tb estive vendo para disponibilizar via JSon, para Delphi por ex.
Com essas alteracoes q vc comentou nossos modelos ficam ate parecidos 
Agora Estou mais em duvida msm, com o DAO Generico, se faco ou nao.
Oq vc indica ?
[quote=feltraco]Na vdd nao comecei a desenvolver ainda.
Mas se trantando de FLEX, nao sao WS nao, eh via AMF consumindo diretamente os metodos na AplicationService.
Tb estive vendo para disponibilizar via JSon, para Delphi por ex.
Com essas alteracoes q vc comentou nossos modelos ficam ate parecidos
Agora Estou mais em duvida msm, com o DAO Generico, se faco ou nao.
Oq vc indica ?[/quote]
Se você for utilizar JPA acho que é interessante criar uma interface genérica para as operações de CRUD.
Nesse caso eu recomendo você montar um pequeno modelo de persistência e testar alguns casos com o banco.
Eu já ví várias implementações de DAOs genéricos por ai, acho interessante fazer um projetinho para testar alguns modelos na prática.
Teriamos algo parecido com isso entao, as divisoes de camadas:
Onde a Service, controla transacao e gerencia Entity e Repository.
Vou colocar o Spring pra gerenciar as transacoes, injecao de dependencia e mais uma coisinha q nao lembro o nome agora rs rs
