Probleminha OOAD (DDD Repositórios)

This message was edited 1 time. Last update was at 14/08/2009 12:39:30

luistiagos wrote:Poxa agora me veio um pensamento... reservas estão sempre associadas a um quarto... vc so pode fazer uma reserva para um quarto disponivel correto? não poderemos fazer reservas para algo que não seja um quarto... em meio disto vemos uma relação: "reserva x quarto" para existir uma reserva deve existir um quarto disponivel... vendo desta forma um esta ligado com outro... pq então não unimos os 2 e matamos a reserva? pq não utilizamos apenas o repositorio quartos com atributo com o periodo de indisponibilidade?

Não mate a reserva, por favor!

Se fizer isso poderá ter muitos problemas futuros! (Eu já fiz isso

)

No primeiro sistema no qual trabalhei, que foi para uma pequena pousada, interpretamos que não haveria necessidade de uma entidade Reserva, pois quando uma pessoa reservava um quarto nós criávamos direto uma conta com as diárias e através das diárias tínhamos como saber se a pessoa já havia efetuado o check-in, ou seja, se já havia ocorrido uma ocupação. Nós ignoramos o fato de que na linguagem do especialista no domínio a palavra reserva aparecia constantemente e tinha um significado essencial para o negócio. Isso se mostrou um erro com o passar do tempo.

fantomas wrote:
Link_pg wrote:Entramos agora numa questão filosófica: "Vale a pena ferir as regras há muito estudadas por especialistas em favor de uma possível 'facilitação' no desenvolvimento da arquitetura?"

Carinha, essa frase entre aspas ficou parecendo um tipo de elixir revigorante para pogueiro.

ahuehueaheua vou imprimir e colar aqui na minha baia, do lado do Dijkstra is watching e do poster do curintia!!

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

Link_pg wrote:Entramos agora numa questão filosófica: "Vale a pena ferir as regras há muito estudadas por especialistas em favor de uma possível 'facilitação' no desenvolvimento da arquitetura?"

Acho que podemos criar outro tópico pra isso, o que vocÊs acham?

O que acontece quando os especialistas pensam uma coisa, mas o caminho ótimo para alcançar o objetivo é outro? Quando seguir a risca o DDD piora o sistema (em performance)?

Isso me lembra um pouco a questão do "Object-relational impedance mismatch", o mapeamento é menos que perfeito.

This message was edited 1 time. Last update was at 14/08/2009 13:19:48

Bruno Laturner wrote:O que acontece quando os especialistas pensam uma coisa, mas o caminho ótimo para alcançar o objetivo é outro? Quando seguir a risca o DDD piora o sistema (em performance)?

É, isso é verdade. Até porque o foco do DDD não é a performance em si, o que acaba depreciando-a nesse caso, o que não é nada bom pois em software a performance é sim muito importante. Acredito que o melhor dos casos é o bom senso... não há como uma teoria (como o DDD) garantir que todos os aspectos não funcionais (performance, escalabilidade, manutenabilidade, *idade) de uma aplicação sejam otimizados, algumas vezes até prejudicando-os, portanto não seria nada de outro mundo darmos uma adaptada na modelagem para contemplar um requisito não funcional (sem exageiros, claro).

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3009 Offline

Link_pg wrote:

Bruno Laturner wrote:O que acontece quando os especialistas pensam uma coisa, mas o caminho ótimo para alcançar o objetivo é outro? Quando seguir a risca o DDD piora o sistema (em performance)?

É, isso é verdade. Até porque o foco do DDD não é a performance em si, o que acaba depreciando-a nesse caso, o que não é nada bom pois em software a performance é sim muito importante. Acredito que o melhor dos casos é o bom senso... não há como uma teoria (como o DDD) garantir que todos os aspectos não funcionais (performance, escalabilidade, manutenabilidade, *idade) de uma aplicação sejam otimizados, algumas vezes até prejudicando-os, portanto não seria nada de outro mundo darmos uma adaptada na modelagem para contemplar um requisito não funcional (sem exageiros, claro).

É ai que entra o bom senso e a capacidade do desenvolvedor de escolher a melhor ação a ser tomada...
um bom desenvolvedor não é aquele que resolve o problema pois isto todos fazem... mas sim aquele que escolhe a melhor solução para o problema...

sergiotaborda wrote:
Colocar um repositório de X retornar Y acho que não é lógico. Sendo assim o detalhe tem que ser contornado no design e no modelo para que seja lógico. às vezes temos que ir mais longe. Temos que chegar em algo como Hotel.getQuartosLivresParaReservaEm(Periodo) : Quartos. Isto dá o que você quer, é ainda mais realista que um objeto chamado TodasReservas e é semântico o suficiente para usuarios e programadores.

Não me parece lógico em Domain-Driven eu ter um elemento chamado Hotel sendo que o que eu estou modelando é o funcionando do mesmo. Já tinha respondido aqui que ter esse "Hotel" gera outros problemas também lógicos.

sergiotaborda wrote:
Esquecendo a UL por um pouco, do ponto de vista puramente OO um repositório de X retornar Y é uma violação do objetivo do próprio objeto repositório. Se vc não quer que o repositorio de X retorna sempre X porque vc afirmar que é o repositorio de X se na realidade posso encontrar nele outras coisas ? É como ter um TodasPessoas e ter um TodasPessoas.getAnimaisDeEstimação() : AnimaisEstimação ... animais de estimação não são pessoas, que magia é essa que me permite tirar animais de onde só ha pessoas ?

Não exagera!!!

No meu exemplo não estou misturando tanto as coisas. Reserva é algo intimamente relacionado com Quartos. Repositórios simplesmente representam uma coleção, geralmente de entidades. Portanto, mensagens que eu atire para este objeto denotam a responsabilidade dele. Não me parece sem lógica perguntar algo para um repositório sobre uma coisa que só ele sabe. Só as reservas sabem os quartos disponíveis.

sergiotaborda wrote:
Claro que vc pode optar por dizer que o repositório é agnóstico, que ele não é de X ou Y e que não ha problema algum em TodosX retornarem Y. Ok. Mas por esse mesmo agumento não ha por que ter dois repositórios , um para X e outro para Y. Basta ter um RepositorioGeral que encontra tudo de qualquer tipo.

Exagerou de novo. O EntityManager é o RepositorioGeral, mas usá-lo deste jeito não é Domain-Driven.

sergiotaborda wrote:
Não é preciso ter poderes mágicos ou ser visionário para criar um bom design. É só seguir a regras. O argumento que as regras podem ser dribladas em condições especiais não é lógica para mim e realmente eu vejo isso como um pecado de corrupção.

Eu já sou da opinião que design é algo criativo. Padrões existem como um guia não como regra. Só conhecimento em padrões não faz ninguém um bom designer.

Na sua solução (listada abaixo), você está construindo entidades transientes somente para que seu repositório TodasReservas retorne Reserva[0..*]. Para mim isso não é lógico, e qualquer programador que pegar esse código no futuro não vai ter a mínima idéia de porque você montou uma lista transiente de reservas se no fim o que você queria eram quartos.

sergiotaborda wrote:
d. Faço uma pesquisa em TodasReservas por getReservasPossiveis(Periodo)

Isso irá trazer uma lista de objectos reserva com as datas iguais às do periodo e os quartos iguais aos disponiveis. Se vc quiser mesmo mostrar os quartos vc usar reserva.getQuarto()

É claro que por detrás dos panos vc irá procura apenas os quartos e montar os objettos reserva "on demand" no repositorio porque essas reservas não existem "fisicamente" no banco. Mas existem no dominio. Tanto é que vc está procurando por elas.

Isso aqui abaixo é do agrado de todos?

rodrigoy wrote:Isso aqui abaixo é do agrado de todos?

Acredito que não importa o lado (quarto ou reserva) os questinomentos serão sempre os mesmos, um depende do outro.

A princípio prefiro (ainda) a solução no repositório das reservas, porque estou considerando quarto uma entidade fraca na relação quarto x reserva, inclusive ela (quarto) é agregada da reserva.

E ao observar seu exemplo, me recorre o questionamento: O resultado desta operação é necessário para satisfazer algum requisito?

[]'s

Link_pg wrote:Vale a pena ferir as regras há muito estudadas por especialistas em favor de uma possível 'facilitação' no desenvolvimento da arquitetura?

Neste caso, não é uma regra que um repositório deva sempre retornar a mesma coisa. Repositórios simplesmente representam coleções.

Não me lembro em nenhuma literatura de padrões falando sobre regras. É mais empírico. Quando o GOF foi escrito eles foram claros em dizer que Padrões eram soluções comuns que apareciam no código para problemas específicos. Um padrão é a repetição de um determinado mecanismo dada uma situação. NÃO É UMA REGRA. Se fosse o nome do livro seria Software Design Rules.

Você deve fazer o mesmo caminho para voltar para casa todos os dias. Isso é um padrão. Se você por alguma razão não fizer o mesmo caminho não estará violando uma regra.

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

rodrigoy wrote:

sergiotaborda wrote:
Esquecendo a UL por um pouco, do ponto de vista puramente OO um repositório de X retornar Y é uma violação do objetivo do próprio objeto repositório. Se vc não quer que o repositorio de X retorna sempre X porque vc afirmar que é o repositorio de X se na realidade posso encontrar nele outras coisas ? É como ter um TodasPessoas e ter um TodasPessoas.getAnimaisDeEstimação() : AnimaisEstimação ... animais de estimação não são pessoas, que magia é essa que me permite tirar animais de onde só ha pessoas ?

Não exagera!!! No meu exemplo não estou misturando tanto as coisas. Reserva é algo intimamente relacionado com Quartos. Repositórios simplesmente representam uma coleção, geralmente de entidades. Portanto, mensagens que eu atire para este objeto denotam a responsabilidade dele. Não me parece sem lógica perguntar algo para um repositório sobre uma coisa que só ele sabe. Só as reservas sabem os quartos disponíveis.

Repara na contradição : "Não me parece sem lógica perguntar algo para um repositório sobre uma coisa que só ele sabe" X "Só as reservas sabem os quartos disponíveis".

As reservas não sabem dos quartos disponiveis já que cada reserva só sabe do seu quarto.
Se o Repositório sabe, então não ha problema. O problema é que ele não sabe. Quem sabe qual é o animal da pessoa é a própria pessoa. Quem sabe do quarto da reserva é do próprio quarto.

O repositorio não sabe. Ele vai encontrar. É a sua função no sistema. Como ele encontra é uma questão modelada na implementação. O quê ele encontra é uma questão modelada no contrato .
Então, seja como for que ele procura ele sempre encontra reservas.

Por outro lado repositórios podem comunicar entre si. Portanto, do ponto de vista OO é sempre válido vc executar dentro do repositorio de reservas codigo referente a qualquer entidade. no caso quartos.
O codigo a seguir é válido dentro de TodasReservas

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.

O OnDemandCollection é um objeto especial que tem a interface do contrato (digamos que Collection) mas ele só criar os objetos quando o iterador passa por eles. É claro que vc pode fazer isso num for antes e retornar a coleção já preenchida. O ponto é apenas demonstrar como na realidade, na implementação, não estou manipulando reservas. Contudo, do lado de fora vc veria:

O seu requisito era : "- Ao efetuar a reserva o sistema deverá exibir uma lista de quartos disponíveis para o período da estadia do hóspede. "

Ele está exibindo essa lista. Isso é 100% o que foi requisitado. Não foi requisitado como essa lista seria obtida. Mas existem regras implícitas de como isso vai ser feito. São as regras de OO, as boas práticas, o SoC , a não gambiarra, etc...
Acho que esta solução não viola nem a UL nem OO e portanto tem prioridade sobre as outras.
Acho que já ficou claro que qualquer uma das outras soluções apresentadas como opção não satisfazem todo o mundo.

sergiotaborda wrote:
Claro que vc pode optar por dizer que o repositório é agnóstico, que ele não é de X ou Y e que não ha problema algum em TodosX retornarem Y. Ok. Mas por esse mesmo agumento não ha por que ter dois repositórios , um para X e outro para Y. Basta ter um RepositorioGeral que encontra tudo de qualquer tipo.

Exagerou de novo. O EntityManager é o RepositorioGeral, mas usá-lo deste jeito não é Domain-Driven.

Cuidado. EntityManager é o DomainStore. O DomainStore não é um reposiotrio porque ele não contém regras de dominio de como procurar entidades. Eles executa os critérios, mas ele não é responsável por os montar, ou saber quais são. Um RepositorioGeral seria uma classe que consome um EntityManager(DomainStore) e tem métodos para encontrar qq tipo de coisa. VC teria getHospedes e getQuartos e getReservas tudo na mesma classe.
Sendo assim, re-analise o que eu falei. O ponto era: Objeto unico com todos os métodos de pesquisa (RepositorioGeral) vs Repositorio por Entidade e qual é a regra/força que o faz preferir o segundo ao primeiro.
Essa mesma força é a que impede que Repositório de X retorne Y.

Eu já sou da opinião que design é algo criativo. Padrões existem como um guia não como regra. Só conhecimento em padrões não faz ninguém um bom designer.

Claro que faz. Um processo criativo sem regras não serve para nada porque ninguem o vai entender. Isso é arte abstrata onde não ha bom nem ruim. Fazer software ainda não é uma arte abstrata. É uma arte concreta. As outras pessoas podem qualificá-la simplesmente conhecendo as regras. É por isso que ha bom design e mau design. É por isso que ha padrões e anti-padrões. É por isso que ha refactoring e bad smells. O valor do design (bom/mau) advem das regras e não da opinião ou gosto de ninguem. Assim, bom design é bom para todos e mau é mau para todos. Ainda estamos falando de um oficio baseado em ciência e não apenas em estética ou empirismo.

Fazer o que vc gosta e acha que dá certo é empirismo. Fazer o que as regras dizem é ciencia. A diferença é clara. A primeira vai lhe causar problemas ( como o testemunho do colega que ao não colocar Reservas no sistema se ferrou depois).

Na sua solução (listada abaixo), você está construindo entidades transientes somente para que seu repositório

Correção. Estou criando objectos transientes. Entidades nunca não são transientes.
Isso é um truque de implementação que posso fazer em OO. Em nada isso define o contrato do objeto repositorio.

TodasReservas retorne Reserva[0..*]. Para mim isso não é lógico, e qualquer programador que pegar esse código no futuro não vai ter a mínima idéia de porque você montou uma lista transiente de reservas se no fim o que você queria eram quartos.

Hummm... na realidade ultima, o que eu quero são os identificadores dos quartos, pois sem eles ninguem vai saber de nada. No caso o numero serve como identificador (normalmente até ha uma regra para que o andar esteja contido no numero do quarto e assim ter 2 informações com um unico dado).
Eu quero ver o identificador. Isso não significa que eu procure pelo identificador. Acho que é passivo e aceitável que :

É um mau uso de OO e um modelo muito capenga.
O fato de querer obter e manipular X não significa que tenho que procurar X. Isso é uma falácia.
Eu vou procurar a entidade agregada mais próxima. No caso de Quarto é Reserva. No caso, de item de pedido é Pedido, e assim vai. Eu não procuro item de pedido sem o pedido. Entendo que muitos o façam, mas eu considero isso uma violação do modelo OO para esses objetos. O mesmo que para quarto e reserva.
Enfim, não vejo nenhum mal em utilizar-me da reserva para procurar pelos quartos.

This message was edited 1 time. Last update was at 14/08/2009 21:22:17

Olá a todos , no livro do Page Jones 'Fundamentals of object-oriented design in UML', logo no capitulo 4 onde ele fala de Classes diagrams,ele define e cita um exemplo de associação que o seguinte:

LibraryPatron and LibraryBook geram a associação Borrowing, neste caso a associção é somente 'conceitual', pois eu nao preciso definir( no contexto do livro) nenhuma operacao em Borrowing. Mas no caso do exemplo temos:

Hospesdes-Quarto -> Reservas

A relação Hospesdes- Quarto gera uma associação Reservas, que neste caso faz sentido transformar a associção em uma classe concreta, visto que esta associação tem responsabilidades proprias.Uma delas seria de encontrar os quartos disponiveis, visto que a disponibilidade do quarto depende da reserva.

Entao essa operacao deveria estar no Repository Reserva, mas concordando com o taborda, o Repository Reserva deve retornar uma lista de reservas, porque isso?

Pensando um pouco, se voce pede a um repositorio que busque informacoes de reserva, porque ele deveria retornar quartos? nao vejo o sentido disso. Ora se quero informacoes do quarto pergunto ao quarto, se quero informacoes de reservas(entenda que reserva aqui e o que diz se um quarto esta disponivel ou nao), peço ao Repository de reservas, uma vez que com a reservas consigo chegar ate o quarto.

Portanto minha opção seria a segunda, com as ressalvas acima.

entenda que reserva aqui e o que diz se um quarto esta disponivel ou nao

Será que é isso que o cliente entende por reserva?

rodrigoy wrote:
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?

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

JavaEvangelist Membro desde: 07/03/2007 15:58:16 Mensagens: 480 Offline

Emerson Macedo wrote:

rodrigoy wrote:
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?

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

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...

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

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.

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