Realmente acho que a opção 1 seria a mais correta…
pois a reserva pode tornar um quarto indisponivel… a reserva conhece o quarto e o quarto não conhece a reserva porem ele pode saber se ele (o quarto) esta ou não disponivel. E vejamos o seguinte… mesmo que não esta no escopo que uma manutenção por exemplo possa indisponibilizar um quarto hoje… nada impede que amanha este requisito apareça… e se deixarmos esta responsabilidade para a reserva se um dia surgir a manutenção tamo tudo fu***… pois a manutenção desta arquitetura nos dara mais dor de cabeça… Não se pode esquecer que um dos requisitos de uma boa app é ela ter a capacidade de extensão e nunca de alteração…
1º Opção.
Como já falaram o quarto tem que saber responder se ele está ocupado ou não.
A pergunta é: As reservas (que podem ser abstraídas como uma caixinha com Index Cards que ficam lá na recepção) conhecem todos os quartos?
[quote=Link_pg]
Imaginemos como isso seria feito manualmente: um quadro na parede com vários quadradinhos, cada um representando um quarto existente no hotel…[/quote]
Link, não vejo que é uma boa opção persarmos em Domain-Driven só imaginando como o usuário faria na mão. Isso vai gerar abstrações pobres na minha opinião.
Mas na sua idéia, quem saberia se o quarto está reservado ou não para um período? A caixinha que representa o quarto ou os post-its?
Imaginem o conjunto de quartos como os quartos fisicos mesmo (aonde estão as camas, o frigobar e etc…). Eles sabem se as reservas existem ou não?
Não pode não… isso pode gerar uma dependência desnecessária.
[quote=luistiagos]
E vejamos o seguinte… mesmo que não esta no escopo que uma manutenção por exemplo possa indisponibilizar um quarto hoje… nada impede que amanha este requisito apareça… e se deixarmos esta responsabilidade para a reserva se um dia surgir a manutenção tamo tudo fu***… [/quote]
E aquele papo esperto de YAGNI? Simplicidade?
[quote=luistiagos]
pois a manutenção desta arquitetura nos dara mais dor de cabeça… Não se pode esquecer que um dos requisitos de uma boa app é ela ter a capacidade de extensão e nunca de alteração…[/quote]
Introduzir dependência desnecessária é o que ferra a sua arquitetura… O quarto, no mundo real, nunca sabe se ele está em manutenção ou não (o diagrama acima não muda o problema original, só postei aqui como ficaria a solução menos acoplada para a questão “quartos em manutenção” - não vamos complicar ainda mais a discussão).
Saber os quartos disponíveis tem mais a ver com quartos ou com Reservas?
Acho que tem mais a ver com reservas. Ao contrário da maioria, não acho adequado um quarto saber se está reservado ou não. Fico com a opção dois.
rodrigoy ,
Acho que o luistiagos se referiu a manutenção do sistema e não ao quarto do hotel.
flws
Não não, fantomas, ele foi claro, certo luistiagos?
(inclusive naquela parte do fu****)
Verdade, havia me esquecido desta parte.
Valeu!
Eu ficaria com o Repository de Reservas, considerando em minha opinião que temos Reservas com informações de quais os quartos reservados em determinados periodos.
Ops, desculpe … o objetivo são os quartos disponveis e não indisponíveis. 
Eu acredito que realmente pelo fato de eu querer os quartos disponíveis por periodo eu teria que saber das reservas os quartos reservados e por consequência trazer do repoistorio dos quartos os que não estão reservados. axo que precisariamos mais que um unico local.
eu me referi a manutensão do quarto… não vejo problema em delegar para o quarto saber se ele esta disponivel ou não… não importando o que lhe torne indisponivel… penso da seguinte forma… se o quarto não sabe se ele esta disponivel ou não… se quem sabe isto e a reserva… se surge um elemento diferente da reserva?
no caso delegando a responsabilidade para a reserva como vc resolveria então se um dia seu cliente coloque um terceiro fator que indisponibiliza o quarto? diferente da reserva? como manutenção, interditação, limpeza ou outro fator que não seja a reserva?
sobre este diagrama:
vendo que ambas as classes tem os periodos em comum… sujeria colocar uma interface Periodo onde qualquer elemento que possa inviabilizar um quarto implemente e esta interface faça sua agregação com o quarto… e não 2 classes identicas como na figura… assim não gera dependencias desnecessarias… apenas tera uma dependencia com uma interface e não se importaremos com quem a implemente…
Só uma sugestão: que tal trocar TodosQuartos.getDisponiveis(periodo) por TodosQuartos.disponiveisEm(periodo) ?
Nomes são importantes. E se a língua escolhida para nomear as coisas for o português, provavelmete não existirá esse ‘get’ na linguagem do domínio.
[quote=Documento de Visão]4. A reserva é associar um período de tempo a um quarto, se uma pessoa quiser mais de um quarto são consideradas duas reservas; O sistema deve impedir reservas duplicadas de quartos em um mesmo período;
- O hóspede pode prorrogar a sua estadia, mas se existir reservas para o quarto que ele está, deve-se verificar a possibilidade de transferir a reserva para outro quarto de mesma classificação. Se a transferência não for possível, deve-se oferecer um quarto de classificação maior ao hóspede (nesse caso, o hospede seria transferido e uma nova reserva criada). Somente em último caso deve-se negar a prorrogação, porém, as reservas feitas com antecedência devem sempre ser respeitadas; [/quote]
Reservas já são associações de quartos com períodos, e a reserva é o componente crítico da disponibilidade dos quartos. O repositório Reservas é que responde por essa lista.
Mesmo se escolhêssemos a opção 1, ela ainda teria que consultar as Reservas. Escolheria a opção 2 também para evitar duplicação da responsabilidade, ou delegação desnecessária.
luistiagos, colocar mais requisitos vai mudar o problema, e com isso a discussão como um todo. Como falei, vamos esquecer essa questão manutenção de quartos e outros. Há outras maneiras de colocar mais requisitos e gerar as mudanças que provem qualquer ponto de vista. Vamos nos ater somente a Quartos e Reservas. OK? (de qualquer forma, não vejo a sua sugestão como melhor opção, podemos discutir depois).
Atentem o seguinte: A disponibilidade do quarto é temporal. A questão não é simplesmente “o quarto saber se ele está ocupado ou não”. A questão é: “na data xx/xx/xxxx o quarto está ocupado?”. Isso tem relação com quartos ou com reservas?
É, até seria plausível o quarto ter um atributo “disponivel”. Agora quem disponibiliza ou não disponibiliza, por quanto tempo, etc. é onde está o porém.
Bom, como já disseram, internamente o repositório de quartos poderia usar o repositório de reservas para definir quais os disponíveis, já que todos pertencem ao domínio. No caso poderia ser uma implementação tipo a do bruno77sa, mas sem usar um service e usando o que o viniciusv colocou:
public class TodosQuartos {
public Set disponiveisEntre(Date inicio, Date termino) {
Set todosQuartos = getTodosQuartos();
Set quartosReservados = new TodasReservas().getQuartos(inicio, termino);
Set quartosDisponiveis = todosQuartos.removeAll(quartosReservados);
// Um pouco de BDUF: :-P
// quartosDisponiveis = quartosDisponiveis.removeAll(new AlgumaOutraCoisaQueTorneOQuartoIndisponivel().get());
return quartosDisponiveis;
}
}
No caso de ter que lidar com outros tipos de indisponibilidade, bastaria trabalhar este método. Mas mesmo levando em conta apenas os requisitos colocados eu ainda deixaria a responsabilidade com o repositório de quartos. Mas é apenas minha opinião! (por enquanto)
Essa discussão tá bem interessante!
Err… vocês não acham isso um pouco estranho não?
(depois me falam que a UML não serve para nada)
Ainda continuo indicando as reservas para tomar conta disto.
flws