Paginação e Ordenação em DDD

[euprogramador]

procure ler sobre o Supple Design. Ele determina práticas como IntentionReavelingInterfaces de forma que sua interface revela o que deve ser feito.

Obrigado pela referência estou olhando…

[feliperod]

O que acontece é o seguinte eu tenho os ManagedBeans do jsf que pertence a camada de aplicação, e coloquei a interface do repositório na camada de dominio e a implementação na infraestrutura, desta forma que demonstrei o repositório realmente sabe demais sobre a infraestrutura, o que recomenda então é criar um objeto que será responsável por acessar o banco e ficará na infraestrutura, e tanto o managed bean e o repositório o acessaria?

ficando assim

...
// método do managed bean
public void recuperarListagem(){
    listaDeClientes = usuario.igual("nome","Carlos Alberto").igual("ativo",true).ordenadoPor("nome",descending).listagem(1,40);  
}
...

talvez assim fique melhor. Não sei… tem que avaliar o caso.

public void listar(){
    listaDeClientes = usuario.withName("Carlos Alberto").ativo(true).repositorio().ordenadoPor("nome",descending).listagem(1, 40);
}

O repositório seria também poderia acessar o QueryObject, mas agora ele tem uma interface mais especifica como:

...
// método da interface do repositorio
public List<Usuario> recuperarUsuariosNaoAtivos();
...

Seria assim?

Acho que essa interface pro repositorio está boa sim. O nome do método é bem explicativo. Talvez fique melhor se você achar um jeito de dizer que é ordenado. Isso normalmente é resolvido por named paramaters em linguagens dinâmica. No Java pode ser inviável. Mas vale tentar.

[quote=euprogramador]
Outra, o que tenho notado com DDD é que o código de negócio (Service) fica bem pequeno, mas temos muito código nas camadas para suportar o serviço, é assim mesmo?[/quote]
O Código de negócio deve ficar na camada de domain. Nos Services, Entities, Value Objects.
É um assunto mesio extenso pra explicar pelo forum sem ser abstrato demais. Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Mas de qq forma, as outras camadas não devem conter regras de negócio. Verifique se o Service que você mencionou é o Service que o DDD menciona (conceitualmente). Verifique se a sua camada de domain possue um limite claro… Verifique se cada camada está cumprindo unica e exclusivamente o seu papel.
Ah… cuidado pra não confundir regra de negócio com regra de apresentação.

E é isso. =)

[euprogramador]

Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Onde vai ser? eu sou de brasília.

[feliperod]

[quote=euprogramador][quote=feliperod]
Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.
[/quote]

Onde vai ser? eu sou de brasília.[/quote]
Vai ser em sampa… =(
Mas quem sabe a gente marca um em Brasilia qualquer dia desses. Só arrumar lugar e rachar as despesas da viagem entre a galera aí que eu vou. =)
QQ coisa me contata em PVT.

[euprogramador]

[quote=feliperod]
Onde vai ser? eu sou de brasília.[/quote]
Vai ser em sampa… =(
Mas quem sabe a gente marca um em Brasilia qualquer dia desses. Só arrumar lugar e rachar as despesas da viagem entre a galera aí que eu vou. =)
QQ coisa me contata em PVT.[/quote]

De boa, a gente pode ver sim, valeu;

[sergiotaborda]

[quote=sergiotaborda]Bom, então só posso concluir que vc não faz testes automáiticos no seu software… porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?
[/quote]

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.

O MiddleHEaven é por causa do principio DRY , porque ficar implementando a mesma coisa 300 vezes ? e já que vai fazer , faz direito ( easy said than done)

Muito boa sua iniciativa. O código parece bem legal também. No entanto, tenho preferido evitar todo este esforço. É uma guerra que nunca termina para seu projeto não ficar acoplado a framework nenhum.

Isso não é dificil, é impossivel. toda a aplicação é amarrada a aquilo que se chama a plataforma de aplicação.
A plataforma de aplicação é um “framework” que vc usa para criar a aplicação. normalmente vc cria esta plataforma
fazendo uma “mushup” de frameworks que tratam partes especificas (Spring para Ioc , Hibernate para persistencia, JSF para apresentação, CFX para webservices, Commons-upload para tratar downlods , etc…) Só que é meio frankeinstein. Vc não isola esses frameworks e um dia vc bate com “putz não dá para fazer isso no X” onde X é um dos frameworks.

Essas plataformas frankeinstein funcionam bem durante um tempo, mas não para sempre.

Enquanto não houver algo pronto que eu possa reaproveitar prefiro resolver as coisas de formas simples e facilmente refatoráveis. Acho que ambas idéias são aceitáveis.

Já existe algo pronto. os frameworks “on rails” são isso mesmo. E são mais ainda fazendo integração com ferramentas como compiladores, mavem e outros. o Grails é um exemplo prático. Ele usa Spring, hibernate , etc ,mas vc não precisa vê esses frameworks.

O MiddlHeaven não segue o caminho on rails, mas é uma plataforma de aplicação. A ideia é dependender apenas dela e deixar ela depender de quem for preciso.

Hum… provavelmente porque usa os framework errados.Escolher frameworks com flexibilidade suficiente não é simples.

Será mesmo? Acho que fazer o contrário é tão difícil quanto, ou seja, adaptar o domínio aos benefícios dos frameworks.

Um exemplo, o jasperReports é excelente para integração com outros frameworks “acima”. Já o JFreeReport é uma porcaria.

[Thiago_Senna]

[quote=Thiago Senna][quote=sergiotaborda]Bom, então só posso concluir que vc não faz testes automáiticos no seu software… porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?
[/quote]

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.
[/quote]

Não utilizo servidor de continuidade. Testo sem a camada de UI numa boa. Testo Domain + Persistência pois não acho necessário separá-los. Para casos onde é muito importante testar o negócio sem persistência é só usar mock. Qual é a dificuldade nisso?

[feliperod]

[quote=sergiotaborda][quote=Thiago Senna][quote=sergiotaborda]Bom, então só posso concluir que vc não faz testes automáiticos no seu software… porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?
[/quote]

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.
[/quote]

Não utilizo servidor de continuidade. Testo sem a camada de UI numa boa. Testo Domain + Persistência pois não acho necessário separá-los. Para casos onde é muito importante testar o negócio sem persistência é só usar mock. Qual é a dificuldade nisso?[/quote]

Não vou opinar se está certo ou se está errado. Mas eu daria uma dica para você ler sobre benefícios do TDD. O TDD consiste em escrever o teste antes do código. Isso facilita o design de cada classe. Individualmente. Nesse caso, por nào separar o Domain da persistência, fica claro que não são testes unitários.

Outra coisa é que dificuldade para testar individualmente siginifica, na maioria dos casos, problemas de design.

Vale a pena investigar.

[Thiago_Senna]

[quote=feliperod]Não vou opinar se está certo ou se está errado. Mas eu daria uma dica para você ler sobre benefícios do TDD. O TDD consiste em escrever o teste antes do código. Isso facilita o design de cada classe. Individualmente. Nesse caso, por nào separar o Domain da persistência, fica claro que não são testes unitários.

Outra coisa é que dificuldade para testar individualmente siginifica, na maioria dos casos, problemas de design.

Vale a pena investigar.[/quote]

Sempre que escrevo testes é utilizando TDD. Se eu não escrever os testes primeiros eu tenho certeza q não vou escrever os testes depois.

Talvez o problema não esteja exatamente nos testes. Como puderam notar, sou um tanto “revoltado”, rsrs. Eu meio que cansei desta arquitetura defensiva onde se faz tudo pensando de que no futuro alguem vai mudar o mecanismo de persistência, de que derrepente o cliente muda o framework de UI entre outras coisas.

Sempre que pegamos um projeto e precisamos produzir vejo meu tempo sendo consumido criando interfaces, sua respectiva implemetação ao invés de simplesmente criar a implementação. Isso é revoltante pq analisando qualquer outra linguagem vemos que essa separação absurda só acontece na comunidade java. Resumindo… simplesmente quero resolver o problema e acabo me vendo a todo momento lidando com um monte de burocracia que todo programador acha que não pode viver sem.

Oras, se um desenvolvedor conhece bem os benefício de criar sua arquitetura com tudo separadinho, se ele por acaso querer juntar tudo de novo será que não pode sair alguma coisa boa daí?

Com certeza separar tudo não está errado. Mas juntar tudo denovo é o que estou testando fazer. É legal remar contra a maré

UPDATE: Obs: Alguns dos meus testes não se enquadram como teste unitário. Mas já é algum teste automatizado e aplico TDD.

[sergiotaborda]

Oras, se um desenvolvedor conhece bem os benefício de criar sua arquitetura com tudo separadinho, se ele por acaso querer juntar tudo de novo será que não pode sair alguma coisa boa daí?

Não pode. Esta é a vantagem de entender os principios de OO.
Vc pode pensar , dentro do seu espectro de experiencia, que assim é melhor. Pode ser mais rápido, mas não é melhor.

O desacoplamento não se faz porque o banco pode mudar, mas porque se usam 2 bancos (um “real” e um de testes).
O desacoplamento não é uma decoração, é uma necessidade. Mas se vc não desacopla , bom é com vc. Sempre pode refactorar depois

O ponto é o seguinte : aquilo que é bem feito por design não precisa se refactorado. Refactorar , ao contrário do que muita gente pensa, não é uma tecnica salva tudo mas sim a exumação de código morto, mal feito, ruim, acoplado, etc… Refactorar serve para tornar seu codigo melhor, mas se seu codigo já nasce bom, não ha porque refactorar = não se perde tempo com isso.

[Thiago_Senna]

Não pode. Esta é a vantagem de entender os principios de OO.

:?

Vc pode pensar , dentro do seu espectro de experiencia, que assim é melhor. Pode ser mais rápido, mas não é melhor.

Sim, concordo em partes.

O desacoplamento não se faz porque o banco pode mudar, mas porque se usam 2 bancos (um “real” e um de testes).

Talvez não estejamos nos entendendo aqui. Isso pq tenho conseguido ter uma base pra testes e desenv.

O desacoplamento não é uma decoração, é uma necessidade. Mas se vc não desacopla , bom é com vc. Sempre pode refactorar depois

Acho que essa é a idéia - refatorar se necessário.

O ponto é o seguinte : aquilo que é bem feito por design não precisa se refactorado.

Então não precisa de testes também, certo? Em minha opinião, independente do design, é passível de refatoração.

Refactorar , ao contrário do que muita gente pensa, não é uma tecnica salva tudo mas sim a exumação de código morto, mal feito, ruim, acoplado, etc… Refactorar serve para tornar seu codigo melhor, mas se seu codigo já nasce bom, não ha porque refactorar = não se perde tempo com isso.

Aqui realmente descordamos, mas cada um cada um No meu ver, um dos benefícios mais interessantes do TDD é me dar garantia de que posso refatorar.

[sergiotaborda]

[quote]

O desacoplamento não é uma decoração, é uma necessidade. Mas se vc não desacopla , bom é com vc. Sempre pode refactorar depois

Acho que essa é a idéia - refatorar se necessário.

O ponto é o seguinte : aquilo que é bem feito por design não precisa se refactorado.

Então não precisa de testes também, certo? Em minha opinião, independente do design, é passível de refatoração.

Refactorar , ao contrário do que muita gente pensa, não é uma tecnica salva tudo mas sim a exumação de código morto, mal feito, ruim, acoplado, etc… Refactorar serve para tornar seu codigo melhor, mas se seu codigo já nasce bom, não ha porque refactorar = não se perde tempo com isso.

Aqui realmente descordamos, mas cada um cada um No meu ver, um dos benefícios mais interessantes do TDD é me dar garantia de que posso refatorar.[/quote]

Existe refactorar e existe refactorar. Existe vc refactorar porque o seu codigo é uma porcaria e não atende a uma nova demanda e existe refactorar porque o seu codigo não é abstrato o suficiente. A primeira forma é um outro tipo de POG que básicamente assenta no principio “se posso refactorar porquê fazer isso agora?” A segunda acontece quando vc não tinha informação suficiente para ter abstraido mais, agora que tem essa informação a abstração é natural. Este é o tipo “saudável” de refactoração.

Agora, lá pq vc precisa abstrair não significa que consegue. Se o seu design é bom, vc não pensa sequer em refactorar e sim em implementar de um jeito diferente a interface X ou Y. Se o seu design é bom, vc não pensa em implementar um novo tipo de banco de dados (tipo = XML, LDAP , map/reduce) e sim configurar uma nova conexão. Entende o nivel da diferença ?

TDD não dá garantia de um bom design. Aliás nenhuma *DD dá essa garantia. Para isso precisa voltar ao B-A-BA de OO e entender as coisas como elas são. E quandio vc faz isso vc não precisa de *DD.

O que lhe dá garantia de (boa) refactoração é um bom design. O design com TDD tende a ser melhor que sem TDD porque vc precisa exercitar as coisas isolamente e isso obriga a um desacoplamento maior e a uma inversão de controle mais agressiva. Contudo, essas mesmas propriedades podem ser adquiridas sem TDD. Ou seja, TDD é melhor que nada, mas OO é melhor que TDD.