Será que é isso que o cliente entende por reserva?
No início da discussão, eu havia pensado em colocar em TodosQuartos. Olhando novamente para o texto do requisito, que imagino que tenha sido uma conversa com o usuário/cliente do sistema, mudei de opinião pela seguinte razão:
O hospede quer ficar no hotel, não necessariamente será num quarto. Pode ser que o hotel tenha quarto, suite, chalé, ou qualquer outro espaço passível de hospedagem. Coloco isso só pra reforçar como a coisa pode ser mais abrangente. Dessa forma, o cliente espera receber opções de reserva que por acaso são quartos.
Portanto, como o fluxo parte sempre de uma possibilidade de reserva (i.e. quarto disponível), não vejo motivo para buscar isso em TodosQuartos, mas sim em TodasReservas.
Sobre o que retornar, acredito também que deva retornar uma lista de reservas possívels (i.e. quartos disponíveis) mas objetos Reserva e não Quarto. Dessa forma, quando o hospede escolher a opção de reserva que lhe satisfaz, a próxima ação poderia ser: reserva.confirmar(), por exemplo. Caso contrário, ficaria incoerente termos quarto.reservarPara(periodo), já que Quarto não conhece Reserva.
Claro que ai entram questões técnicas, que não é o ponto da discussão.
[]s
não consegui ler tudo ainda, li mais ou menos metade da discursão.
Acho que o método fica em Todasreservas mesmo. faz mais sentido.
O nome Todasreservas, Todas Pessoas, e etc são melhores que qualquer nome XxxxxRepositório. até pq repositório em portugues não é exatamente a mesma coisa que repository em ingles. eles usam essa palavra com frequência, nós não.
vou ler o resto e depois posto minhas considerações. mas já favoritei o tópico, esse tipo de discursão vale mais que muito curso por ai.
[]'s
[quote=Emerson Macedo][quote=rodrigoy]
Num determinado ponto do sistema há o seguinte requisito:
- Ao efetuar a reserva o sistema deverá exibir uma lista de quartos disponíveis para o período da estadia do hóspede.
Pergunta: Quem responde pela lista de quartos disponíveis para o período?
[/quote]
No início da discussão, eu havia pensado em colocar em TodosQuartos. Olhando novamente para o texto do requisito, que imagino que tenha sido uma conversa com o usuário/cliente do sistema, mudei de opinião pela seguinte razão:
O hospede quer ficar no hotel, não necessariamente será num quarto. Pode ser que o hotel tenha quarto, suite, chalé, ou qualquer outro espaço passível de hospedagem. Coloco isso só pra reforçar como a coisa pode ser mais abrangente. Dessa forma, o cliente espera receber opções de reserva que por acaso são quartos.
Portanto, como o fluxo parte sempre de uma possibilidade de reserva (i.e. quarto disponível), não vejo motivo para buscar isso em TodosQuartos, mas sim em TodasReservas.
Sobre o que retornar, acredito também que deva retornar uma lista de reservas possívels (i.e. quartos disponíveis) mas objetos Reserva e não Quarto. Dessa forma, quando o hospede escolher a opção de reserva que lhe satisfaz, a próxima ação poderia ser: reserva.confirmar(), por exemplo. Caso contrário, ficaria incoerente termos quarto.reservarPara(periodo), já que Quarto não conhece Reserva.
Claro que ai entram questões técnicas, que não é o ponto da discussão.
[]s[/quote]
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…
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.
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
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…
[quote=YvGa]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… [/quote]
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
[quote=rodrigoy][quote=sergiotaborda]
// 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.
[/quote]
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.[/quote]
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.
É 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 [b]itens são controlados /b 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.
[quote=rodrigoy]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. [/quote]
Blz Marcio, mas qual é a sua resposta para a pergunta do Rodrigoy?
flws
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.
[quote]
a. O repositório de Quartos? b. O repositório de Reservas?[/quote]
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.
Não.Naturalmente é uma aplicação standalone, ou talvez dependa da tecnologia ser for um beanshell poderia sim.
:shock: :shock: :shock: :shock: :shock: :shock: :shock:
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!
- 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.
[quote=schmidt.marcelo]
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. [/quote]
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)
[quote=sergiotaborda]
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)[/quote]
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.
[quote=mochuara][quote=sergiotaborda]
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)[/quote]
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.[/quote]
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.
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”.
[quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
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)[/quote]
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.[/quote]
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.
[/quote]
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.