Estou tentando implementar um sistema usando os princípios do DDD e me deparei com umas duvidas.
Depois de modelar os objetos do meu domínio criei uma fachada para que a a camada de visão chamasse os métodos de negocio através dela, ou seja, não deixo que a visão(bean do JSF) chame métodos dos objetos de domínio diretamente: ex
Tehno uma classe Aluno
public class Aluno{
//getters and seters
public Boletim visualizarBoletim(String anoSemestre){
//logica
}
}
Aí na fachada tenho:
public class DominioAcademicoFacade{
public Boletim vlisualizarBoletim(Aluno aluno, String anoSemstre){
return aluno. VisualizarBoletim(anoSemestre);
}
public Aluno getAluno(String cpd){
return repositorioAluno.getAluno(cpd);
}
}
E finalmente na visão tenho:
public class CentralDoAlunoBean{
private String cpd;
private String anoSemestreSelecionado;
private Boletim boletim ;
private DominioAcademicoFacade dominioFacade;
//getters and settters
public void vlisualizarBoletim(){
Aluno aluno = dominioFacade.getAluno(cpd);
Boletim = dominioFacade.visualizarBoletim(aluno, anoSemestreSelecionado);
}
}
Isso está correto, ou seria melhor criar DTOS para comunicar com a visão? li aqui no forum que é aconselhável não criar os DTOS mas no caso, gostaria de isolar o domínio da visão , outra coisa , para integrar o sistema com outras aplicações via rest ou webservices é valido criar uma fachada para implementar os WebServices usando DTOS?
[quote=cordjr] Estou tentando implementar um sistema usando os princípios do DDD e me deparei com umas duvidas.
Depois de modelar os objetos do meu domínio criei uma fachada para que a a camada de visão chamasse os métodos de negocio através dela, ou seja, não deixo que a visão(bean do JSF) chame métodos dos objetos de domínio diretamente: ex
Tehno uma classe Aluno
public class Aluno{
//getters and seters
public Boletim visualizarBoletim(String anoSemestre){
//logica
}
}
Aí na fachada tenho:
public class DominioAcademicoFacade{
public Boletim vlisualizarBoletim(Aluno aluno, String anoSemstre){
return aluno. VisualizarBoletim(anoSemestre);
}
public Aluno getAluno(String cpd){
return repositorioAluno.getAluno(cpd);
}
}
E finalmente na visão tenho:
public class CentralDoAlunoBean{
private String cpd;
private String anoSemestreSelecionado;
private Boletim boletim ;
private DominioAcademicoFacade dominioFacade;
//getters and settters
public void vlisualizarBoletim(){
Aluno aluno = dominioFacade.getAluno(cpd);
Boletim = dominioFacade.visualizarBoletim(aluno, anoSemestreSelecionado);
}
}
Isso está correto, ou seria melhor criar DTOS para comunicar com a visão? li aqui no forum que é aconselhável não criar os DTOS mas no caso, gostaria de isolar o domínio da visão , outra coisa , para integrar o sistema com outras aplicações via rest ou webservices é valido criar uma fachada para implementar os WebServices usando DTOS?
[/quote]
Quanto a usar DTOs vc mesmo respondeu a pergunta ao afirmar que quer isolar o dominio da visao. Mas observe que DTOs eram uma solucao construida com a tecnologia da epoca em mente (EJB, JSF, JavaBeans). Hoje em dia, com aplicacaos web minha impressao é que DTOs estao cada vez mais sendo substituidos por formatos padronizados como JSON, XHTML, Atom, etc.
Apenas complementando o mochuara ,
Vc só precisa (deve) usar DTO somente se precisar usar EJB(3).[quote=cordjr] Estou tentando implementar um sistema usando os princípios do DDD e …
public class Aluno{
//getters and seters
public Boletim visualizarBoletim(String anoSemestre){
//logica
}
} [/quote]@cordjr, se está querendo usar os Pricípios da DDD, q tal codificar o Domain com uma API + Fluente. (‘visualizar’ é um verbo de Aplicação Cliente/Front-End, e não de Business-Core; concorda??) Então, no lugar de ‘visualizarBoletim(anoSemestre);’ não seria melhor ‘recuperarBoletimPor(anoSemestre);’??![quote=cordjr]Aí na fachada tenho:
public class DominioAcademicoFacade{
public Boletim vlisualizarBoletim(Aluno aluno, String anoSemstre){
return aluno. VisualizarBoletim(anoSemestre);
}
public Aluno getAluno(String cpd){
return repositorioAluno.getAluno(cpd);
}
}
…[/quote]Neste caso, q tal no Business-Core criar 1 estrutura assim: 1 Diretório (Pacote) chamado Domain(ou Dominio) e dentro dele criar subDiretórios/Pacotes ‘ServiceFacade’, ‘Gerenciador’(se necessário), ‘Repository’, ‘Model’ (p/ Entidades de Negócio e ValueObject’s), etc.??!
O lance de isolar o dominio da arquitetura do sistema é mais conceitual que prática. A idéia é que vc consiga escrever todo o código do seu domínio antes de usar qualquer biblioteca. Se vc fez isso então esta certo.
Agora quanto ao ManagedBean se comunicar com o domínio. Isso não é uma falha e tão pouco esta acoplando o dominio com o JSF, pelo contrário vc esta acoplando o JSF com o domínio. Esta correto.
Facade é legal para criar chamadas que resumem outras chamadas do dominio e não para ser mais uma camada no sistema. Embora seja comum cria-la com este propósito que vc esta usando.
[quote=Daniel.F][quote=mochuara]Não da pra ter tudo. JSF, DDD e Isolamento. Escolha dois.
DDD diz para nao lutar contra seus framework, mas nao diz nada sobre o desgraçado que fez vc usar JSF.[/quote]
E como assim te obriga a usar??
[/quote]
É muito comum existir arquiteturas de referencias nas empresas devido a todo caos causado nao so pela diversidade de frameworks, mas pela pobre integracao entre solucoes de diferentes fornecedores. Neste caso achei que usar JSF fosse uma determinacao da diretoria.
[quote=cordjr]Isso está correto, ou seria melhor criar DTOS para comunicar com a visão? li aqui no forum que é aconselhável não criar os DTOS mas no caso, gostaria de isolar o domínio da visão , outra coisa , para integrar o sistema com outras aplicações via rest ou webservices é valido criar uma fachada para implementar os WebServices usando DTOS?
[/quote]
Pessoal, não concordo com vocês. Primeiro, o que é um “domínio isolado da visão”? Pra isso, vou mostrar um exemplo de um domínio não isolado da visão:
public class Aluno {
public Boletim boletimDoPeriodo(java.util.Date tempoDeInteresse) {
// lógica de busca de boletim
}
public JPanel mostreDetalhe() {
// cria um componente Swing
}
}
O Aluno acima não está isolado da visão porque tem um método de geração de componente Swing! Não existindo nada de Swing, nada de JSF, nada de Wicket, nada de visualização em seu domínio, ele já está isolado da visão!!!
Talvez você quisesse isolar a visão do domínio. Mas isso é totalmente desaconselhável, porque toda visão é a representação de alguma coisa (o domínio). Sem esta coisa, não há visão. Ou seja, não se preocupe com isso porque a visão está naturalmente acoplada ao domínio, nada vai te impedir do contrário. O DTO não cria isolamento porque dependência é transitiva, explicando melhor:
E sua ideia esperta de “isolamento” vai por água abaixo.
Em tempo, DDD não é pura aplicação de patterns. Só existe DDD quando há uma linguagem ubíqua, com que você pode conversar com todos os envolvidos.
[quote=mochuara]Não da pra ter tudo. JSF, DDD e Isolamento. Escolha dois.
DDD diz para nao lutar contra seus framework, mas nao diz nada sobre o desgraçado que fez vc usar JSF.[/quote]
Discordo, existem coisas que exigem compromisso, mas não é o caso.
Por mais que eu não goste de JSF, é possível sim haver JSF, DDD e “Isolamento” (que eu chamaria de um sistema bem modularizado) dentro de um mesmo software.
[quote=Giulliano]O lance de isolar o dominio da arquitetura do sistema é mais conceitual que prática. A idéia é que vc consiga escrever todo o código do seu domínio antes de usar qualquer biblioteca. Se vc fez isso então esta certo.
[/quote]
Pois é, as pessoas dao muita enfase em como isolar porque isso é o que da pra fazer quando se termina de ler um resumo sobre os patterns DDD.
Acontece que DDD realmente trata é de como identificar o dominio. Mas ai é mais dificil, precisa de domain experts. Alem disso o fato que a maioria das empresas tem no maximo um analista de sistemas, cujo perfil pode ser tecnico ou gerencial, mas quase nunca com enfase no negocio, piora a situacao. Hoje em dia DDD virou brincadeira de separar o sistema em camadas que nao fazem o menor sentido, ou camadas anemicas.
Vocẽ discorda da gente e repete a mesma coisa que eu disse acima, com outras palavras !?!?!? Ou vocẽ concorda e não sabe com o que ou vocẽ não concorda mas apresenta outra teoria.
O DTO evita essa interferencia de objetos do JSF, mas isso nao muda o fato que vc teve que usar os DTOs em primeiro lugar por causa do JSF, ou seja, ha uma interferencia mesmo que indireta.
Quanto a comunicacao com apps swing acredito que seja mais comum usar formatos padronizados, como os citados anteriormente.
[quote=Giulliano][quote=Leonardo3001]
Pessoal, não concordo com vocês.
[/quote]
Vocẽ discorda da gente e repete a mesma coisa que eu disse acima, com outras palavras !?!?!? Ou vocẽ concorda e não sabe com o que ou vocẽ não concorda mas apresenta outra teoria.
[quote=mochuara]O DTO evita essa interferencia de objetos do JSF, mas isso nao muda o fato que vc teve que usar os DTOs em primeiro lugar por causa do JSF, ou seja, ha uma interferencia mesmo que indireta.
Quanto a comunicacao com apps swing acredito que seja mais comum usar formatos padronizados, como os citados anteriormente.[/quote]
Não!
Uma classe de domínio só é acoplada à visão por causa de um relapso no design da aplicação, não porque faltou usar DTO.
E outra, se é uma aplicação Swing off-line, usar “formatos padronizados” é canhão pra matar mosca!
[quote=Leonardo3001][quote=mochuara]O DTO evita essa interferencia de objetos do JSF, mas isso nao muda o fato que vc teve que usar os DTOs em primeiro lugar por causa do JSF, ou seja, ha uma interferencia mesmo que indireta.
Quanto a comunicacao com apps swing acredito que seja mais comum usar formatos padronizados, como os citados anteriormente.[/quote]
Não!
Uma classe de domínio só é acoplada à visão por causa de um relapso no design da aplicação, não porque faltou usar DTO.
E outra, se é uma aplicação Swing off-line, usar “formatos padronizados” é canhão pra matar mosca![/quote]
Nao me referi a apps offline, ate porque estas tb nao precisariam de algo como DTO que serve para comunicacao remota.
Galera obrigado pelas opiniões agora está bem mais calro, realmente o dominio precisa ser melhorado e acredito que isso seja meio que incremntal, afinal é dificil acertar de primeira
