Probleminha OOAD (DDD Repositórios)

rodrigoy wrote:Algumas pessoas não entenderam bem, para falar a verdade um quarto tem várias reservas. Reservas são futuras e passadas.

Mas rodrigoy, se um quarto TEM várias reseservas por que no seu modelo (UML) a associação entre as 2 entidades está com a navegação partindo da Reserva para o Quarto me dizendo que eu APENAS consigo navegar das reservas para os quartos e não dos quartos para as reservas?

Abraços

This message was edited 1 time. Last update was at 17/08/2009 16:15:27

Navegabilidade e Multiplicidade são coisas diferentes. Mas isso foi só um comentário sobre o código do Taborda.

Um quarto tem reservas no passado, no presente e no futuro. De qualquer forma, a multiplicidade alí não muda o problema...

Para falar a verdade, achei que isso era meio lógico também. Um quarto pode ter reservas para hoje, para a semana que vêm e para daqui 1,2,3 meses...

This message was edited 1 time. Last update was at 17/08/2009 17:25:08

YvGa wrote:Isso é muito proximo da proposta do Taborda no seu primeiro post nesse topico. Acho que como forma de implementacao é valida, mas parece fugir um pouco da "ubiquitous language", nenhum hospede pergunta pelas reservas possiveis, mas pelos quartos disponiveis.

Esse é o unico empecilho que vejo pra essa decisao, não sei se é motivo suficiente pra nao adotar. Mas pra implementacao da busca acho que é por aí mesmo.

Eu tenho um sistema com um problema parecido, com a diferenca que é roupas em vez de quartos. E eu escolhi o caminho errado, fiz com que as roupas soubessem se estao reservadas ou nao. Como é um aplicativo relativamente pequeno isso nao me da muita dor de cabeca, mas volta e meia eu estou alterando a implementacao de Roupa, quando deveria estar alterando apenas as reservas. Ou seja, o metodo deve estar sim no repositorio de reservas e os quartos nao devem saber nada sobre reservas.

Ja tem até um TODO pra alterar la, mas...

Acho que entendi...

A minha impressão é que vc acredita que a coisa deveria ser solucionada pelo repositorio "TodosQuartos" e não pelo "TodasReservas"; só não entendi ainda exatamente as razões disto. Estou errado?

Eu opto pelo repositorio "TodasReservas" pelo fato de entender que:

a) A reserva pode ser para um quarto, chalé, apartamento etc....
b) Por conta das datas o objeto em questão (o reservado) sempre é o mesmo fazendo com que a importancia quantitativa fique bem reduzida.
c) O item reservado apenas assumiria um status de reservado dependendo da data hora mencionada.
d) Pelo fato de podermos reservar vários tipos de ítens a reserva seria a abstação ideal para controlar todo o processo.
...

Agora veja o relato do YvGa (quote acima), parece que a solução aplicada no repositorio "TodosQuartos" não seria uma boa idéia.

flws

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

rodrigoy wrote:

sergiotaborda wrote:

// usando uma mecanismo de busca qq , vc invoca o seguinte Collection<Quarto> quartos = store.execute( Criteria.search(Quarto.class).where("reserva").isNull() ); return OnDemandCollection<Reservas> (quartos, Periodo);

A reserva tem 1 quarto, mas o quarto tem 1,0 reservas. O quarto está reservado quando ha no sistema uma reserva que o possui.

Algumas pessoas não entenderam bem, para falar a verdade um quarto tem várias reservas. Reservas são futuras e passadas.

Tem outras considerações que farei Taborda... só estou sem tempo agora.

Antes de mais , só para dizer que o texto que escrevi é para um periodo.
O quarto está reservado , no periodo, quando ha no sistema uma reserva , no periodo, que o possui.

Achei que era claro. Tudo o que disse se baseia na limitação ao periodo de busca.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

É bem assim, o hospede liga para o hotel para fazer reserva, o atendente do hotel verifica se existe vaga para reserva , caso ele não tenha a reserva ele comunica ao hospede e pode informar opções de futuras hospedagem ou marcar a reserva no presente momento.

Quando o cliente chega ao hotel, verifica-se junto ao gerente situação de estadia, nesse momento dados do cliente é confirmando e é certificada a estadia.

Existe agora a situação onde o hospede circula dentro do hotel, e instancias começam a surgir relação hospede com ambientes a serem usados fator de consumo e itens são controlados (repositório) todavia existe a forma a de não haver dependência direta com a ação de navegabilidade, ou melhor o cliente pode circular no hotel entre as dependências e não gerar qualquer ação ao controle de consumo sobre as dependencias do hotel sem ocorrência ou abertura de serviços notificados.

Melhor observar assim, tudo o que o objeto cliente depender dentro do hotel invoca controle e gera tarefa, na certa essa informações são refletidas ao repositório do Domínio.

No que vão gerar itens situação de controle, ocorrencia objetocliente nas dependencia do hotel, exemplo uso da lavanderia controle (gera itens), serviço de quarto(gera itens), etc..., caso não, é simplesmente uma navegabilidade ao sistema e consulta ao repositório.

rodrigoy wrote:Pergunta: Quem responde pela lista de quartos disponíveis para o período?

a. O repositório de Quartos?

b. O repositório de Reservas?

c. Faço uma query na UI usando Scriptlet...

Justifique sua resposta.

Blz Marcio, mas qual é a sua resposta para a pergunta do Rodrigoy?

flws

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

fantomas wrote:[rodrigoy]Pergunta: Quem responde pela lista de quartos disponíveis para o período?

Isso é logo no começo quanto o cliente aciona reserva pra ter estadia, mas a demanda de reserva é gerada de arcordo com a consulta da reserva.

a. O repositório de Quartos? b. O repositório de Reservas?

Acredito que existe um unico repositório para consultar tanto quartos quanto reserva, porque haveria mais de um repositorio, sendo que o mesmo é uma abstração do domínio, podemos entender o repositorio como uma coleção em memoria onde os dados estão sempre disponiveis.

c. Faço uma query na UI usando Scriptlet...Justifique sua resposta.

Não.Naturalmente é uma aplicação standalone, ou talvez dependa da tecnologia ser for um beanshell poderia sim.

Smalltalk Membro desde: 18/08/2009 17:33:22 Mensagens: 1 Offline

http://tudogratisnaweb2.blogspot.com/

Smalltalk Membro desde: 14/11/2006 21:57:40 Mensagens: 2 Offline

Não sou muito de falar em fóruns e afins, mas esse problema me fez querer dar a minha opinião.

Grande mestre Yosha! Convenhamos que as informações que temos são muito pobres. Eu diria até que foram "presumidas" pelo programador que acha que conhece o domínio. Na verdade, verdade mesmo, sinceramente, que diferença faz se a coleção de quartos disponíveis vai ser informada pelo repositório de quartos ou de reservas? Isso vai ser refinado nas próximas iterações de qualquer forma, pois os requisitos vão mudar, como já foi dito.

Mas participando da brincadeira, acredito que a responsabilidade de entregar os quartos disponíveis é de um objeto de domínio, não de repositórios. No meu entendimento de DDD, depois de ler a referência do assunto, repositórios fazem parte da camada de infraestrutura, pois como você mesmo disse, repositórios são apenas coleções de objetos. Então, como já foi dito aqui, uma terceira classe (classe de domínio) deve informar a lista de quartos disponíveis.

---

Gostaria de ir um pouco mais a fundo com algumas questões ao pessoal aqui!
1) Um quarto não sabe quando está disponível, reservado, ocupado? Em outras palavras, um quarto não conhece seu "status"?
Implicações: Se o quarto conhece seu status para uma determinada data, significa uma agregação entre quarto e reserva, o que pode fazer com que eu mude a minha opinião e diga que o respositório de quartos PODE informar os quartos disponíveis. Se ele não conhece o status, é só um objeto de dados com informações do quarto (número, andar, etc) e o seu repositório também é "burro";
e 2) Uma reserva é vinculada a um quarto específico?
Implicações: Se sim (o que parece ter sido "presumido" até agora), existe uma relação de composição entre reserva e quarto, o que me diria, nesse caso, que o repositório de reservas DEVE CONHECER o repositório de quartos, o que, por sua vez, faz "nascer" um agregate (o que, por SUA vez, não muda minha resposta ao questionamento). Se não, não há relação nenhuma entre quartos e reservas, o que simplifica muito a abordagem. Você vai ter uma lista (quantidade) de reservas que vai descontar da lista (quantidade) de quartos do hotel, o que vai dizer não QUAIS, mas QUANTOS quartos estão disponíveis.

Existem muito mais coisas escondidas aí. Não dá prá definir com exatidão como deve ser implementado um determinado requisito. Isso é quase BDUF, na minha opinião.

---

Precisamos visitar o hotel prá saber como trabalha. Conversar com o product owner prá saber o que ELE quer. hehehe

---

Enfim, achei muito boa a discussão, gostaria que continuasse, aprendemos muito com essa troca.

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

schmidt.marcelo wrote:
Mas participando da brincadeira, acredito que a responsabilidade de entregar os quartos disponíveis é de um objeto de domínio, não de repositórios. No meu entendimento de DDD, depois de ler a referência do assunto, repositórios fazem parte da camada de infraestrutura, pois como você mesmo disse, repositórios são apenas coleções de objetos.

alguma coisa foi perdida durante a sua leitura ... Repositorios não são coleções de objetos. Eles parecem coleções de objetos.
Depois,não parecem coleções de objetos quaisquer, e sim de Entidades. (Não existe repsoitorio de String)
Por fim, Repositorios sim são objetos do dominio, porque contêm regras de pesquisa.Regras de pesquisa são inevitávelmente atreladas ao dominio. (como o caso em estudo mostra)

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:
alguma coisa foi perdida durante a sua leitura ... Repositorios não são coleções de objetos. Eles parecem coleções de objetos.
Depois,não parecem coleções de objetos quaisquer, e sim de Entidades. (Não existe repsoitorio de String)
Por fim, Repositorios sim são objetos do dominio, porque contêm regras de pesquisa.Regras de pesquisa são inevitávelmente atreladas ao dominio. (como o caso em estudo mostra)

Primeiramente repositórios é uma responsabilidade do domínio, nao necessariamente um objeto. Quanto a regras de pesquisa depende muito de cada caso. Um caso não é suficiente pra provar nada. Principalmente discutindo um pseudo dominio.

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

mochuara wrote:

sergiotaborda wrote:
alguma coisa foi perdida durante a sua leitura ... Repositorios não são coleções de objetos. Eles parecem coleções de objetos.
Depois,não parecem coleções de objetos quaisquer, e sim de Entidades. (Não existe repsoitorio de String)
Por fim, Repositorios sim são objetos do dominio, porque contêm regras de pesquisa.Regras de pesquisa são inevitávelmente atreladas ao dominio. (como o caso em estudo mostra)

Primeiramente repositórios é uma responsabilidade do domínio, nao necessariamente um objeto. Quanto a regras de pesquisa depende muito de cada caso. Um caso não é suficiente pra provar nada. Principalmente discutindo um pseudo dominio.

O que vc escreveu não faz nenhum sentido para mim.
Exactamente porque as regras de pesquisa dependem de cada caso que é necessário o reposiotorio (esse é o problema que ele tenta resolver) Segundo, se algo é uma responsabilidade , em OO alguma objeto terá essa responsabilidade. Isso é o básico do Principio de Separação de Responsabilidades. Não ha como ter algo no dominio e isso não ser responsabilidade de um objecto. Todo este tópico trata repositorio como algo que um objeto é.
Poderia argumentar que pode ser responsabilidade de um conjunto de objetos. Sim, poderia, mas não no caso especifico do repositorio.

Afirmar que "repositorio" é um conceito/responsabilidade/algo abstrato do dominio que não é um objeto é contra sensu para
uma discussão OO onde exactamente se discute qual dos objetos repositorios tem a responsabilidade de prover os objetos de certa
entidade.

Smalltalk Membro desde: 14/11/2006 21:57:40 Mensagens: 2 Offline

Grande sergiotaborda. Obrigado pelo puxão de orelha.

Realmente me expressei mal, repositórios são (ou melhor, parecem) coleções de ENTIDADES.

Mas isso não muda muito a minha opinião. Prá ter uma resposta mais segura, vai depender muito das respostas aos questionamentos que lancei.

De um lado, se quartos conhecem seu status, o repositório dos quartos pode retornar os disponíveis. Se não conhece, aí o mais lógico seria ter outra classe OU o repositório de reservas o responsável pela informação. Na real, não faz muita diferença a essa altura do projeto. Como mochuara já falou, não temos informações suficientes prá dar uma resposta "certa".

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:

mochuara wrote:

sergiotaborda wrote:
alguma coisa foi perdida durante a sua leitura ... Repositorios não são coleções de objetos. Eles parecem coleções de objetos.
Depois,não parecem coleções de objetos quaisquer, e sim de Entidades. (Não existe repsoitorio de String)
Por fim, Repositorios sim são objetos do dominio, porque contêm regras de pesquisa.Regras de pesquisa são inevitávelmente atreladas ao dominio. (como o caso em estudo mostra)

Primeiramente repositórios é uma responsabilidade do domínio, nao necessariamente um objeto. Quanto a regras de pesquisa depende muito de cada caso. Um caso não é suficiente pra provar nada. Principalmente discutindo um pseudo dominio.

O que vc escreveu não faz nenhum sentido para mim.
Exactamente porque as regras de pesquisa dependem de cada caso que é necessário o reposiotorio (esse é o problema que ele tenta resolver) Segundo, se algo é uma responsabilidade , em OO alguma objeto terá essa responsabilidade. Isso é o básico do Principio de Separação de Responsabilidades. Não ha como ter algo no dominio e isso não ser responsabilidade de um objecto. Todo este tópico trata repositorio como algo que um objeto é.
Poderia argumentar que pode ser responsabilidade de um conjunto de objetos. Sim, poderia, mas não no caso especifico do repositorio.

Afirmar que "repositorio" é um conceito/responsabilidade/algo abstrato do dominio que não é um objeto é contra sensu para
uma discussão OO onde exactamente se discute qual dos objetos repositorios tem a responsabilidade de prover os objetos de certa
entidade.

Definir repositórios como uma responsabilidade (ao inves de objeto) de domínio me deixa livre para implementar o repositório fora do domínio, enquanto sua interface continua pertencente ao domínio.

Quanto a critérios de pesquisa, IMO se ela pertence de fato ao domínio (depende de cada caso) talvez devesseser implementada em outro objeto para não violar o principio da responsabilidade única (SRP) do repositório que é fornecer um ponto de acesso ao aggregate. Além do benefício de oferecer uma oportunidade de representar critérios de busca fazendo sentido para o especilista de domínio, repositórios são geralmente um conceito estranho para eles.

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