Paginação e Ordenação em DDD

Olá pessoal,

Estou estudando o livro sobre DDD e estou achando muito interessante os conceitos apresentados, mas estou com dificuldades para entender algumas coisas, como pode ser implementada a paginação de resultados de serviços que exigem um processamento de muitas instancias de classes? e ordenação?

Como vocês tem implementado estes dois conceitos tanto para a tela como para o domínio?

Obrigado.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Os métodos dos repositórios podem receber parâmetros indicando o offset, o máximo e talvez até a ordenação.

Se pensarmos no repositório como uma implementação de collections, podemos concluir que é de responsabilidade dele, o repositório, cuidar da organização, retorno e ciclo de vida dos dados.

A implementação prática depende muito da estratégia da sua paginação. Mas se for 1 query para cada página por exemplo, supondo que estamos falando de DBs relacionais, eu repassaria esses parâmetros para os DAOs. Mas há casos e mais casos. =)

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Eu já acho que ordenação e paginação não é problema do repositório. Depois de muito quebrar a cabeça decidi mandar o DAO e o Repositório pra cucuia. Como opção, comecei criando as queries usando session diretamente. Depois refatorei, encapsulando as queries dentro de query objects.

Acho muito ruim implementar paginacao usando DAO ou Repositório pois eu preciso de no mínimo dois métodos:

Outro problema que tive é que usando o banco de dados hsqdb (pelo menos) eu não consigo utilizar a mesma query para fazer a busca e o count. Isso pq quando adiciona ordenação na minha criteria o count simplesmente quebra. Ai, lá vai gambi pra organizar tudinho.

enfim... resumindo:

public abstract class DefaultHibQuery<T> implements Query<T> {

@Dependency
	private SessionFactory sessionFactory;

protected abstract DetachedCriteria buildDetachedCriteria();
	
	protected Order[] ordering() {
		return new Order[] {};
	}

public int count() {
		DetachedCriteria detached = buildDetachedCriteria();
		Criteria crit = toCriteria(detached, false);
		crit.setProjection(Projections.rowCount());
		
		return (Integer) crit.uniqueResult();
	}

@SuppressWarnings("unchecked")
	public Collection<T> findAll() {
		DetachedCriteria detached = buildDetachedCriteria();
		Criteria crit = toCriteria(detached, true);
		return crit.list();
	}

@SuppressWarnings("unchecked")
	public Collection<T> findAll(int first, int count) {
		DetachedCriteria detached = buildDetachedCriteria();
		Criteria crit = toCriteria(detached, true);
		crit.setFirstResult(first);
		crit.setMaxResults(count);
		return crit.list();
	}

@SuppressWarnings("unchecked")
	public T findFirst() {
		DetachedCriteria detached = buildDetachedCriteria();
		Criteria crit = toCriteria(detached, true);
		crit.setMaxResults(1);
		return (T) crit.uniqueResult();
	}

protected Criteria toCriteria(DetachedCriteria detached, boolean applyOrdering) {
		Session sess = sessionFactory.getCurrentSession();
		Criteria crit = detached.getExecutableCriteria(sess);
		
		if (applyOrdering) {
			for (Order order : ordering()) {
				crit.addOrder(order);
			}
		}
		
		return crit;
	}
	
}

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

euprogramador wrote:Olá pessoal,

Estou estudando o livro sobre DDD e estou achando muito interessante os conceitos apresentados, mas estou com dificuldades para entender algumas coisas, como pode ser implementada a paginação de resultados de serviços que exigem um processamento de muitas instancias de classes? e ordenação?

Como vocês tem implementado estes dois conceitos tanto para a tela como para o domínio?

Obrigado.

Eu uso um objeto de paginação (algo nas linhas disto) mas o segredo aqui é objeto Query que não é um conjunto de objetos mas um Fastlane para refazer a pesquisa várias vezes.

Moral da historia, vc resolve com bom OO. DDD não lhe vai ensinar isso.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Thiago Senna wrote:Eu já acho que ordenação e paginação não é problema do repositório. Depois de muito quebrar a cabeça decidi mandar o DAO e o Repositório pra cucuia. Como opção, comecei criando as queries usando session diretamente. Depois refatorei, encapsulando as queries dentro de query objects.

Acho muito ruim implementar paginacao usando DAO ou Repositório pois eu preciso de no mínimo dois métodos:
Repositorio.findAll(int first, int count); Repositorio.findAllCount();

Outro problema que tive é que usando o banco de dados hsqdb (pelo menos) eu não consigo utilizar a mesma query para fazer a busca e o count. Isso pq quando adiciona ordenação na minha criteria o count simplesmente quebra. Ai, lá vai gambi pra organizar tudinho.

enfim... resumindo:

Ótimo, agora pega o seu objeto Query e chama ele de dentro do repository. \o/

A implementação não precisa ficar no repository. Porém se você excluir o repository e começar a criar métodos alternativos para manipular os dados, estará ferindo os principios do DDD. Como o Sergio falou, você resolve isso com bom OO e o DDD vai funcionar normalmente como em qualquer outro caso.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

feliperod wrote:Ótimo, agora pega o seu objeto Query e chama ele de dentro do repository. \o/

Pra que?

feliperod wrote:A implementação não precisa ficar no repository.

Sim, de fato!

feliperod wrote:Porém se você excluir o repository e começar a criar métodos alternativos para manipular os dados, estará ferindo os principios do DDD.

Mas que dados alternativos são esses que só seria interessante manipular dentro de um repositório?

feliperod wrote:Como o Sergio falou, você resolve isso com bom OO e o DDD vai funcionar normalmente como em qualquer outro caso.

Pode ser, mas dá muito trabalho. Usar query object já é bem elgante se falando de OO. Quanto a DDD, manter os repositórios se transformou em uma guerra contra os frameworks que utilizo.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Thiago Senna wrote:

feliperod wrote:Ótimo, agora pega o seu objeto Query e chama ele de dentro do repository. \o/

Pra que?

Bom, os benefícios do uso de repositório são vários. O Eric Evans cita que sem eles o risco é que o domain fique "limboso" (de limbo mesmo).
Entendo que o caso não seja muito óbvio se levarmos em consideração somente o caso da paginação, mas estamos falando de um sistema maior, certo?

Thiago Senna wrote:

feliperod wrote:Porém se você excluir o repository e começar a criar métodos alternativos para manipular os dados, estará ferindo os principios do DDD.

Mas que dados alternativos são esses que só seria interessante manipular dentro de um repositório?

Não dados alternativos, eu disse métodos alternativos ou formas alternativas. Por exemplo obter os dados por fora, sem o repositorio em algumas vezes e em outras obter através do repositorio. O ponto de acesso a dados deve ser único. Para isso servem os repositórios.

Thiago Senna wrote:

feliperod wrote:Como o Sergio falou, você resolve isso com bom OO e o DDD vai funcionar normalmente como em qualquer outro caso.

Pode ser, mas dá muito trabalho. Usar query object já é bem elgante se falando de OO. Quanto a DDD, manter os repositórios se transformou em uma guerra contra os frameworks que utilizo.

Bom, dois pontos... primeiro, QueryObject é uma solução inteligente de OO. Pode ser utilizada em conjunto com os repositórios.

Quanto ao caso dos frameworks, eu concordo que às vezes é difícil de manter. Em casos como o Rails/Grails por exemplo, é uma opção ignorar o uso de repositórios, mas aproveitar outros conceitos do DDD. Eu faço isso frequentemente.
Para modelos mais complexos ou maiores, mesmo com esses frameworks, eu aconselho o uso dos repositorios. Talvez a dificuldade de uso possa se revelar uma má separação das camadas? Talvez. Eu investigaria.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

feliperod wrote:Entendo que o caso não seja muito óbvio se levarmos em consideração somente o caso da paginação, mas estamos falando de um sistema maior, certo?

Humm, acredito que o tamanho do projeto não é o problema. A quantidade e a qualidade dos desenvolvedores poderiam afetar se a arquitetura será mais "burocrática" ou mais "froxa".

feliperod wrote:Não dados alternativos, eu disse métodos alternativos ou formas alternativas. Por exemplo obter os dados por fora, sem o repositorio em algumas vezes e em outras obter através do repositorio. O ponto de acesso a dados deve ser único. Para isso servem os repositórios.

Então, no meu caso afroxei. No caso de obter os dados por fora será sempre através de QueryObjects. Uma operação mais complexa envolvendo mais entidades coloca-se em um Service. Outra operações como load, save e remove tenho abstraído nos próprios componentes de UI.

feliperod wrote:Quanto ao caso dos frameworks, eu concordo que às vezes é difícil de manter. Em casos como o Rails/Grails por exemplo, é uma opção ignorar o uso de repositórios, mas aproveitar outros conceitos do DDD. Eu faço isso frequentemente.

Eu tenho buscado dia a dia uma produtividade similar a Rails e Grails, no entanto, utilizando Java, Spring, Hibernate e Wicket. Num cenário como este manter o repositório se tornou uma guerra contra esses frameworks, mesmo. Isso se agravou principalmente por causa do Wicket, já que não é tão complicado criar componentes de UI um pouco mais espertos.

feliperod wrote:Para modelos mais complexos ou maiores, mesmo com esses frameworks, eu aconselho o uso dos repositorios. Talvez a dificuldade de uso possa se revelar uma má separação das camadas? Talvez. Eu investigaria.

Sinceramente... tenho achado que em geral, nós desenvolvedores java, criamos camadas demais. Outros frameworks e linguagens tem se saído tão bem com arquiteturas tão mais simples. Então, por enquanto, vou tentar seguir esta receita. O mínimo de camadas possíveis. Caso necessário, no decorrer do projeto, refatoramos para algo mais "defensivo".

Na medida do possível, a idéia é manter e aplicar as boas idéias do DDD, só que inicialmente sem o repositório, que é onde a briga contra os frameworks é mais intensa.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Thiago Senna wrote:

feliperod wrote:Como o Sergio falou, você resolve isso com bom OO e o DDD vai funcionar normalmente como em qualquer outro caso.

Pode ser, mas dá muito trabalho. Usar query object já é bem elgante se falando de OO. Quanto a DDD, manter os repositórios se transformou em uma guerra contra os frameworks que utilizo.

QueryObject é um padrão , mas como todos os padrões pode ser usado da forma errada. QueryObject precisa ser usado conjuntamente com um Interpreter. No seu caso o objeto é QO e Interpreter ao mesmo tempo

portanto violando o
principio de responsabilidade e portanto não sendo OO elegante ( esquece elegante, não é bom OO para começo de conversa)

O problema de não usar QueryObject conjuntamente (cooperação) com um outro objeto - neste caso o repositorio que faria o papel
de interpreter - é o acoplamento. Com um QO desassoiado do repistorio vc pode ter muito mais flexibilidade porque pode mandar o mesmo QO para reposiotorios com implementações diferentes (um real e um de teste, por exemplo).

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Leal Thiago, parece que estamos entrando em consenso agora. =)

Thiago Senna wrote:

feliperod wrote:Quanto ao caso dos frameworks, eu concordo que às vezes é difícil de manter. Em casos como o Rails/Grails por exemplo, é uma opção ignorar o uso de repositórios, mas aproveitar outros conceitos do DDD. Eu faço isso frequentemente.

Eu tenho buscado dia a dia uma produtividade similar a Rails e Grails, no entanto, utilizando Java, Spring, Hibernate e Wicket. Num cenário como este manter o repositório se tornou uma guerra contra esses frameworks, mesmo. Isso se agravou principalmente por causa do Wicket, já que não é tão complicado criar componentes de UI um pouco mais espertos.

Só reparei que talvez sua dificuldade para usar os respositorios esteja exatamente na aplicaçào do smart-UI ou componentes UI mais espertos. Não digo que é certo ou errado, mas muitos, inclusive o Eric Evans menciona no livro, o pattern Smart-UI exclui mutuamente o uso do MDD, permitindo o uso das outras pŕaticas do DDD.

Thiago Senna wrote:Na medida do possível, a idéia é manter e aplicar as boas idéias do DDD, só que inicialmente sem o repositório, que é onde a briga contra os frameworks é mais intensa.

Esse é o espírito. =)

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

sergiotaborda wrote:O problema de não usar QueryObject conjuntamente (cooperação) com um outro objeto - neste caso o repositorio que faria o papel de interpreter - é o acoplamento. Com um QO desassoiado do repistorio vc pode ter muito mais flexibilidade porque pode mandar o mesmo QO para reposiotorios com implementações diferentes (um real e um de teste, por exemplo).

Entendo, entendo. Mas em minha opinião este esforço não tem valido a pena. Nada contra em implementar um bom OO, mas a real é que no fim, se vc juntar tudo que você implementou para fazer tudo ficar bonitinho praticamente vira um framework novo. Não é a toa que você está desenvolvendo o MiddleHeaven, certo?

Infelizmente aplicar patterns, OO, separação de camadas e essas coisas de forma bonitinha é sofrido demais. Principalmente hoje dependendo de qual framework vc está adotando.

Humm.. deixe eu levantar uma questão interessante baseado em uma colação que você fez:

sergiotaborda wrote:O problema de não usar QueryObject conjuntamente (cooperação) com um outro objeto - neste caso o repositorio que faria o papel de interpreter - é o acoplamento.

Hoje, utilizando wicket, ainda posso colocar o interpreter fora do repositorio. Eu poderia numa boa criar um componente de UI que fizesse a interpretação do QueryObject. Melhor fazer isso do que criar o componente de UI, que chama o repositório e que por fim, chama o QueryObject. IMHO é muita delegação. A maioria dos projetos não precisam ser defensivos a este ponto, acho. E vocês, o que acham?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

feliperod wrote:Leal Thiago, parece que estamos entrando em consenso agora. =)

Thiago Senna wrote:

feliperod wrote:Quanto ao caso dos frameworks, eu concordo que às vezes é difícil de manter. Em casos como o Rails/Grails por exemplo, é uma opção ignorar o uso de repositórios, mas aproveitar outros conceitos do DDD. Eu faço isso frequentemente.

Eu tenho buscado dia a dia uma produtividade similar a Rails e Grails, no entanto, utilizando Java, Spring, Hibernate e Wicket. Num cenário como este manter o repositório se tornou uma guerra contra esses frameworks, mesmo. Isso se agravou principalmente por causa do Wicket, já que não é tão complicado criar componentes de UI um pouco mais espertos.

Só reparei que talvez sua dificuldade para usar os respositorios esteja exatamente na aplicaçào do smart-UI ou componentes UI mais espertos. Não digo que é certo ou errado, mas muitos, inclusive o Eric Evans menciona no livro, o pattern Smart-UI exclui mutuamente o uso do MDD, permitindo o uso das outras pŕaticas do DDD.

Humm, Smart-UI? Não li este capítulo! Valeu pela dica, Filipe.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Thiago Senna wrote:Humm, Smart-UI? Não li este capítulo! Valeu pela dica, Filipe.

Veja o link abaixo. É muito interessante e trata sobre o Smart-UI.
http://codeidol.com/csharp/domain-driven-design/Isolating-the-Domain/The-Smart-UI-Anti-Pattern/

Em português tem esse aqui ó:
http://andersonleiteblog.wordpress.com/2009/03/07/model-driven-design-e-isolamento-do-dominio/

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

feliperod wrote:

Thiago Senna wrote:Humm, Smart-UI? Não li este capítulo! Valeu pela dica, Filipe.

Veja o link abaixo. É muito interessante e trata sobre o Smart-UI.
http://codeidol.com/csharp/domain-driven-design/Isolating-the-Domain/The-Smart-UI-Anti-Pattern/

Em português tem esse aqui ó:
http://andersonleiteblog.wordpress.com/2009/03/07/model-driven-design-e-isolamento-do-dominio/

Valeu, acabei de dar uma lida em ambos para comentar aqui.

(depois leio com mais calma)

Curti os artigos. A única parte assustadora é que de cara eles citam o Smart-UI como um anti-pattern. Com certeza, se considerar que o Smart-UI faz selects na base, sem dúvida nenhuma a lista de desvantagens será grande.

Já no caso como estou implementando tá rolando algo um pouco diferente, talvez, um Semi-Smart-UI (rsrs). A lógica de negócio e queries ainda continuarão (ou pelo meno devem continuar) no domínio.

Quero também destacar este trecho:

There are other solutions in between SMART UI and LAYERED ARCHITECTURE. For example, Fowler (2002) describes the TRANSACTION SCRIPT, which separates UI from application but does not provide for an object model. The bottom line is this: If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design.

Eu tenho tomado este cuidado. Bom saber que mesmo ousando na camada de UI é possível se falar em DDD.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Thiago Senna wrote:
Valeu, acabei de dar uma lida em ambos para comentar aqui. (depois leio com mais calma)

Curti os artigos. A única parte assustadora é que de cara eles citam o Smart-UI como um anti-pattern. Com certeza, se considerar que o Smart-UI faz selects na base, sem dúvida nenhuma a lista de desvantagens será grande.

Já no caso como estou implementando tá rolando algo um pouco diferente, talvez, um Semi-Smart-UI (rsrs). A lógica de negócio e queries ainda continuarão (ou pelo meno devem continuar) no domínio.

Quero também destacar este trecho:

There are other solutions in between SMART UI and LAYERED ARCHITECTURE. For example, Fowler (2002) describes the TRANSACTION SCRIPT, which separates UI from application but does not provide for an object model. The bottom line is this: If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design.

Eu tenho tomado este cuidado. Bom saber que mesmo ousando na camada de UI é possível se falar em DDD.

Na verdade o Smart-UI é um anti-pattern no contexto do Model Driven Development. Se você não se propor a usar o MDD, então o Smart-UI não é um Anti-Pattern.

O DDD é um processo de práticas, onde uma complementa a outra. Se usarmos várias práticas do DDD mas não usarmos o MDD, estamos também fazendo DDD?
Eu acho que sim.

Não gosto de pensar que quem faz DDD é o bom e quem não faz é o ruim. Gosto de pensar que o DDD nos sugere uma série de práticas por um motivo. Essas práticas se justificam pelos benefícios que elas apresentam. Então eu gosto de pensar: Tal projeto está usufruindo dos benefícios totais. Tal projeto está usufruindo de parte dos benefícios, pois não aplica todas as práticas. Tais projetos não se beneficiam por que não aplicam boas práticas.

Assim, acho mais justo. No seu caso, você deve estar se beneficiando pelo menos de algumas práticas. Talvez até possa evoluir para ter ainda mais benefícios. Talvez nem precise. Cabe a você julgar isso. =)

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