[quote=Domain Driven Design]
Client Code Ignores REPOSITORY Implementation; Developers Do Not
Encapsulation of the persistence technology allows the client to be very simple, completely decoupled from the implementation of the REPOSITORY. But as is often the case with encapsulation, the developer must understand what is happening under the hood. The performance implications can be extreme when REPOSITORIES are used in different ways or work in different ways.
Kyle Brown told me the story of getting called in on a manufacturing application based on WebSphere that was being rolled out to production. The system was mysteriously running out of memory after a few hours of use. Kyle browsed through the code and found the reason: At one point, they were summarizing some information about every item in the plant. The developers had done this using a query called “all objects,” which instantiated each of the objects and then selected the bits they needed. This code had the effect of bringing the entire database into memory at once! The problem hadn’t shown up in testing because of the small amount of test data.
This is an obvious nono, but much more subtle oversights can present equally serious problems. Developers need to understand the implications of using encapsulated behavior. That does not have to mean detailed familiarity with the implementation. Well-designed components can be characterized. (This is one of the main points of Chapter 10, “Supple Design.”)
As was discussed in Chapter 5, the underlying technology may constrain your modeling choices. For example, a relational database can place a practical limit on deep compositional object structures. In just the same way, there must be feedback to developers in both directions between the use of the REPOSITORY and the implementation of its queries.[/quote]
[quote=Domain Driven Design]
Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.[/quote]
Daqui a pouco vai ser possível ler o livro todo neste tópico…
Muito bom o artigo sobre DDD. Aliás, a revista toda tá boa.
Uma dica, na minha opinião, é colocar alguma coisa sobre J2ME… a última que foi acho que já faz mais de 1 ano… eu nem comprei por achar que ela tá desatualizada.
[quote=rodrigoy]Eu não vou criar uma pilha de classes só para dizer que estou usando um repositório “puro” por ter medo que se fizer diferente não vou ser entendido (ou criticado).
[/quote]
E eu não vou criar uma classe POJO e chamar-lhe um repositório , factory, façade, sei-lá-o-que só para por num artigo e esperar que o leitor ache que eu sei o que estou fazendo. Fazer o quê … ? Cada uma sabe de si.
Isso não cabe a mim decidir.
O ponto não era mostrar a supra-suma implementação de Repository, mas mostrar a diferença de nivel (responsabilidade) entre Repository e DAO. E por uma vez segui o padrão tal e qual Fowler o definiu. Só para não conflituar com as suas crenças. E mesmo assim vc acha ruim. Parece-me que no fim de contas vc faz o que bem entende e usa as citações para tapear quem não vê no código o mesmo que vc vê.
O ponto é: Padrão é uma regra formal ou é uma ideia abstracta que pode ser identificada em qualquer classe ?
Para mim, padrão é uma regra formal (porque é uma linguagem). Se eu implemento Singleton, Repository etc… eu tenho que seguir as regras. Caso contrário eu não posso chamar de Singleton , Repository, etc…
O que vc está sarcásticamente insinuando é que eu construo todas as minhas classes como implementações de padrões. Não foi isso que eu disse. Eu construo classes. Ponto final. Se um dia eu entendo que é bom usar o padrão X ou Y eu implemento rigorosamente o padrão. Ai a classe será uma implementação do padrão.
O que eu não faço é construir uma classe da minha cabeça e dizer que ela implementa o padrão X apenas por “lembra” ou “parece” o padrão X. Isto é muuiiito diferente do que vc entendeu.
No caso do DDD , VO é claramente diferente de Entity, que são claramente diferentes de Service.
Se eu crio uma classe sem estado eu não posso dizer que é um service. Para ser um service essa classe tem que manipular objetos do dominio. Façade não é um Service se manipula mecanismos de infra ( por exemplo)
e se a classe não manipula mais do que um tipo de camada ela não é um Façade. (Ou seja, uma implementação de Façade não pode ser simultaneamente uma implementação de Service ) E assim vai. Os conceitos são importantes. É só isso que estou dizendo.
No fim, vc tem uma classe e o sistema funciona. Otimo. Mas não estamos discutindo o funcionamento. Estamos discutindo os conceitos por detrás das classes.
Básicamente vc está defendo o velho “Se funciona é bom”. Cara, para seguir essa filosofia eu não preciso saber nada sobre nada de teoria de computação , DDD, TDD etc… eu simplesmente faço codigo, ponho a funcionar e pronto.
Quem procura DDD e outras correntes filosoficas do mesmo tipo, procura um nivel acima do “Se funciona é bom”. Neste ponto o cara sabe o impirico, ele quer saber mais do teorico, para codificar de forma mais tecnica. Ou seja, o objetivo é codificar bem não apenas codificar.
Vc não entendeu nada. Não preciso de haja outro ser humano defendendo a mesma coisa para eu a defender também. Não sou um “maria-vai-com-as-outras”.
Não me interessa quem defende o quê. Acho apenas que é uma questão de logica. Se as regras não são para se cumprir de quê adiantam ? Se as regras são para serem dribladas , isso não é POG ? Se eu não vou seguir a regras porquê eu vou perder tempo aprendendo qual é ? Cara, porque vc fez faculdade se não vai seguir nenhuma das regras que aprendeu ? Defender que as regras não são para se cumprir é ilógico.
Mas não quero perder mais tempo mostrando a ilogicidade do seu pensamento. É muito cançativo.
Os pontos que eu queria discutir já foram discutidos:
DDD inclui um dialogo sobre padrões de projeto, em particular padrões de dominio: VO, Entity, Aggregatino, Service e Repository. Eles são necessários ao completo entendimento e uso de DDD em Java.
Retirá-los do nucleo da DDD levaria a conclusões de que a DDD é incompleta. E não se pode ter as duas coisas. Ou é incompleta e é inutil, ou é completa e os padrões têm que ser referidos.
Os padrões são pouco conhecidos. Mal implementados a maioria das vezes. A separação de responsabilidade não é executada corretamente. E não é aceitável dizer-se que houve um sacrifício da formalidade do padrão para tornar as coisas mais ágeis. Isso não é agilidade é gambiarra**.
Se a classe não formaliza o padrão, não ha problema nenhum. Basta não andar dizendo por ai que formaliza. Ou seja, não ha porquê mentir. Se a classe quer formalizar, então que formalize direito.
O ponto é : Quem entrou no DDD entrou também porque quer fazer essa formalização. O interessante seria discutir essa formalização ( como está sendo feito em outro tópico e já foi feito em muitos outros antes. Todas essas discussões pecam pelo mesmo motivo: falta de conhecimento do padrão e falta de cuidado em formalizar o padrão. Por isso seria interessante ver isso no artigo)
** É discutivel se é gambiarra ou agilidade. Depende da perspectiva de cada um. já ficou claro que a minha é diferente da sua. Não é necessário nos repetirmos mais. Mas o sacrificio da formalidade não é discutivel. É como aceitar que se pode escrever errado para escrever mais depressa. Não é aceitável. Embora muita gente o faça.
Sem a referencias aos dois pontos anteriores o artigo mencionado na revista é incompleto. Isto não é nenhum juizo de valor sobre o autor , editor e /ou revisores do artigo. É apenas a minha opinião. E não, não tenho outros autores que defendem a mesma ideia … mas existem outros participantes do GUJ que defendem. Serve ?
:idea:Já deu para perceber que Design Patterns tem suas respectivas aplicações pela interpretação ao melhor contexto do cenário Corporativo e isso sendo transparente ao emprego de sua metodologia, sendo esses FDD, DDD, TDD.
Estes não vão partir de conceitos rígidos ou baseado em biografias de livros ou autores, mas sim no que cabe o recurso nos três pilares ao entendimento dos patterns à ser empregado, se esse for de Criação tal-concepção e melhores pratica , se for de Comportamento tal-concepção e melhores práticas por fim se for de Estrutura tal-concepção e melhores práticas.
Pouco se falou, de case de sucesso ou se provou em foco de DDD, entre outras aqui nessa discurssão, o que torna provável que não existe um unico caminho a se seguir.
[quote=mrmarcondes]Concordo que as ultimas edicoes da MundoJava estao excelentes, deixo como sugestao para as proximas edicoes:
como vender um projeto utilizando processos ágeis.
Uma das grandes barreiras que vejo na adocao de processos ágeis eh vender, por exemplo, um projeto em uma instituicao financeira, cheia de procedimentos e documentos e concorrer com uma grande consultoria (3 letras e/ou nome de banda emo) que adota processos de desenvolvimento tradicional e que, de certa forma, ja conhecem os caminhos para realizar a venda.
Marco.[/quote]
Bom, voltando ao tópico original…
Engraçado, instituições financeiras deveriam ser as primeiras a adotar projetos ágeis, iterativos e incrementais. Eles deveriam conhecer os termos do mundo financeiro. Vá para o presidente do banco e mostre o seguinte quadro:
[size=18][color=red]Projeto Waterfall dentro de Fábrica de Software = Operação arriscada a descoberto
[/color]
[color=blue]Projeto Ágil Iterativo e Incremental = Hedge
[/color][/size]
Não, não… a minha ideia tb não é essa… a minha ideia era fomentar um debate como esse sobre a tecnologia (leia-se a cultura DDD).
Todos sabemos que é perfeitamente possivel fazer um sistema sem usar DDD, seja este em qualquer nivel de complexidade, tamanho, etc… Arquiteturas mais simples resolvem o mesmo problema com muito menos esforço como o gerado pelo DDD no desenvolvimento, concordam?
Só pra constar, a “primeira parte” da materia que fala mais sobre o DDD e a OL está perfeita… como falei antes, acho que uma passada nos DDD Patterns deveriam conter esses debates…[/quote]
Fica o convite!!! Se alguém quiser escrever uma artigo sobre alguma coisa com uma crítica construtiva a outra, terá as portas abertas na MundoJava! É só entrar em contato comigo!
[quote=dedejava]Muito bom o artigo sobre DDD. Aliás, a revista toda tá boa.
Uma dica, na minha opinião, é colocar alguma coisa sobre J2ME… a última que foi acho que já faz mais de 1 ano… eu nem comprei por achar que ela tá desatualizada.
Abraço.[/quote]
Pode aguardar um tópico bem quente na área de Java ME para a próxima edição!
É bem difícil achar pessoas para escrever um artigo “estilo MundoJava” sobre a plataforma Java ME. A maioria das propostas que recebemos são sobre temas mais batidos, que já foram publicados ou que existem diversos materiais sobre ele na internet. Também deixo o convite para os interessados!
Acompanhei a discussão entre você e o Rodrigo até aqui, e pelo que vejo, os conflitos de idéias não são entre as definições de Repositório adotadas por você e ele, e sim, entre o conceito de Repositório apresentado por Martin Fowler e o reapresentado por Eric Evans.
Não li o livro do Martin Fowler e, portanto, não tenho condições de discutir esse padrão. Mas pelo que você explicou, Fowler diz que a única finalidade do repositório é abstrair a recuperação dos objetos ( consultas ). Mas Evans é claro quanto à capacidade do repositório de cuidar também da persistência.
Não li o livro do Martin Fowler e, portanto, não tenho condições de discutir esse padrão. Mas pelo que você explicou, Fowler diz que a única finalidade do repositório é abstrair a recuperação dos objetos ( consultas ). Mas Evans é claro quanto à capacidade do repositório de cuidar também da persistência.
O que você acha?[/quote]
Sim, vc entendeu certo. Existem dois “sabores” de repositorio.
O repositorio do Fowler é apenas uma boa ideia de OO. É o seguimento estricto do SoC. O do DDD é algo mais.
O DDD chega a um conceito semelhante ao do Fowler, mas partindo de outro lugar.
O Fowler parte do problema de ter construção de queries espalhada pelo sistema todo e o resolve colocando-as num objeto chamado Repositorio. A ideia é que o Repositorio representa, para o resto do sistema, um ponto de obtenção de dados.
O DDD parte do conceito de que as instancias das entidades formam um conjunto. Esse conjunto é a matéria-prima do dominio.
Os objetos do dominio dedicam-se a operar sobre esse conjunto. Esse conjunto é encarado como uma coleção mas onde não é prmitido iterar todos os itens. Para obter os itens é necessário realizar pesquisas com significado. Por exemplo, o repositorio de itens de pedido contém todos os itens de todos os pedidos, mas só faz sentido obter os itens de um pedido em particular.
Os dois conceitos são muito semelhantes. Partem da ideia de um objeto que funciona como se fosse um façade para uma coleção, mas onde as pesquisas são “inteligentes”. A diferença é que no mecanismo do Fowler não ha necessidade de métodos de manipulação dos dados (insert, update, remote) porque isso é feito por outros padrões, mas no DDD não é. Isso faz o repositorio do DDD ser mais semelhante ainda a uma coleção.
Isso é tudo muito bonito ,mas como é a implementação dessa tralha toda. A do Fowler é simples. O repositorio pega os dados do dominio, cria uma query e a executa. Intrepreta o resultado e retorna. Ele é apenas um mediador. Não há logica de alteração dos dados consultados. Não ha problema de concorrência, etc… é um simples read-only.
Em DDD o repositorio é mais complexo. Como ele é read-write a implementação é mais rubusta para lidar com problemas de concorrencia, por exemplo. O Repositorio do DDD é confundido com qualquer coisa que acesse dados do dominio. Isso é muito vasto. Em tese o reposiorio pertence ao dominio, mas aceitando que qq coisa pode ser o Repositorio desde que fornceça dados, então API inteiras - que não são de dominio- poderia ser o repositorio. Isso não faz nenhum sentido.
Na prática, vc usa um mecanismo de persistencia, seja o Hibernate o JPA ou o velho JDBC. Para que esse mecanismo faça pesquisas vc precisa montar a pesquisa. Seja em SQL, HSQL ou Criteria. Se vc espalhar essa montagem pelo sistema vc vai ter um codigo esparguete. Quando uma regra mudar vc tem que garimpar onde ela está sendo montada a query… Então a ideia é simplesmente montar essas pesquisas num objeto centralizado. Esse objeto é o repositorio do Fowler. Neste cenário vc não precisa de um repositorio mutável como o do DDD já que usa o Hibernate / JPA/ etc… directamente para dar insert , update, etc…
Isso viola se certa forma a ideia do DDD de que apenas o dominio sabe sobre o dominio. Mas se vc colocar um métodos save que delegam para a API de persistencia tb não vem nenhum mal ao mundo. O repositorio então se comporta como um autentico façade para a persistencia do dominio em todos os aspectos. Contudo a existencia destes métodos não significa que tudo tenha que passar pelo repositorio. Numa tela de cadastro (que está fora do dominio) vc pode simplesmente invocar o save do hibernate e pronto. Os métodos do repositorio são para ser usados apenas pelo dominio, mas a aplicação são mais coisas além do dominio.
É nessas outras coisas que o Fowler suprime lacunas enquanto o DDD para na fronteira do dominio.
Segundo Fowler a definição é a mesma e ele indica o livro do Evans como a melhor fonte sobre o assunto. Para ambos o Repositório é, basicamente, um meio de consulta.
[quote=DDD, Descricao do Repository]A client needs a practical means of acquiring references to preexisting domain objects. If the infrastructure makes it easy to do so, the developers of the client may add more traversable associations, muddling the model. On the other hand, they may use queries to pull the exact data they need from the database, or to pull a few specific objects rather than navigating from AGGREGATE roots. Domain logic moves into queries and client code, and the ENTITIES and VALUE OBJECTS become mere data containers. The sheer technical complexity of applying most database access infrastructure quickly swamps the client code, which leads developers to dumb down the domain layer, which makes the model irrelevant.
[…]
FACTORIES and REPOSITORIES have distinct responsibilities. The FACTORY makes new objects; the REPOSITORY finds old objects.
[…]
One other case that drives people to combine FACTORY and REPOSITORY is the desire for “find or create” functionality, in which a client can describe an object it wants and, if no such object is found, will be given a newly created one. This function should be avoided.
[/quote]
