Como mencionei Tarso, é um draft e não uma implementação que descrevi. Com certeza teria para o “find” uma lista de parâmetros no código de produção além de outras coisas.
Mas essa lista de parâmetros (ou como tbm mencionei, um QueryObject com diferentes traduções e argumentos), não tem nada específico de qualquer API… logo não é dependência.
[quote=Lezinho]Como mencionei Tarso, é um draft e não uma implementação que descrevi. Com certeza teria para o “find” uma lista de parâmetros no código de produção além de outras coisas.
Mas essa lista de parâmetros (ou como tbm mencionei, um QueryObject com diferentes traduções e argumentos), não tem nada específico de qualquer API… logo não é dependência.[/quote]
Entendo, mas não deixa de ser uma gambiarra, porque eu não usaria essa lista de parâmetros se não fosse com JDBC ( ia ter que passar um valor null ).
Acho que o melhor a fazer é estudar mais o QueryObject.
[EDIT]
Ahhhh… O método find do DAO que eu mostrei tá errado… Ele deve retornar um List<T>.
[/EDIT]
Eu já nem entro mais nessas discussões… não adianta… quando será que vocês vão compreender que DDD não é sobre padrões? O nível de cerimônia e de débito técnico pode variar entre as aplicações. Não dá pra pegar a literatura e aplicar "as-is" como uma cartilha.
Vou falar uma coisa aqui que posso até ser crucificado por vocês: uma aplicação com domínio anêmico na implementação pode ser desenvolvida usando DDD. Depende do domínio. 8)
Um Active Record do Ruby é manifestado declarando claramente dependência de infra:
class PedidoVenda < ActiveRecord::Base
...
endCreio que na opinião de vocês não dá pra desenvolver nada em DDD no Rails. Só no mundinho hermético onde temos Entities, Hibernate, DAOs, Camadas é que podemos ter DDD, certo?
Vamos imaginar que eu consiga manifestar um conceito de domínio na "YoshiLanguage" da seguinte maneira:
Pedido é Entidade
Código é Número-Inteiro
Cliente é Empresa
Valor-Total é Número-Decimal
Itens é Item-Pedido[]
Status é Em-Aberto, Aprovado, Entregue, Cancelado
Fim
Pedidos é Repositório de Pedido
Cancelados é cada Pedido onde Status = Cancelado
Fim
TelaPedido é Tela
Tabela-de-Pedidos é Tabela
Iniciar
Tabela-de-Pedidos popular-com Pedidos.Cancelados
Fim
FimVocês poderiam dizer que nessa listagem não estamos usando DDD por que os padrões não estão claros como na literatura ou porque tenho dependências de conceitos da minha implementação?
[quote=rodrigoy]Eu já nem entro mais nessas discussões… não adianta… quando será que vocês vão compreender que DDD não é sobre padrões? O nível de cerimônia e de débito técnico pode variar entre as aplicações. Não dá pra pegar a literatura e aplicar "as-is" como uma cartilha.
[/quote]
Acho que você viajou aqui, Rodrigo. Ninguém, até onde eu lembro, está comentando sobre Domain-Driven Design em si e sim sobre os padrões de apoio.
Falar isso sem dar um exemplo ou embasamento é uma afirmação vazia.
Além de você estar colocando palavras no texto de todos aqui (estamos discutindo sobre padrões, não sobre aplicação de DDD em si) essa afirmação é meio sem-sentido. Repository não fala sobre a implementação de persistência, por exemplo, e nada impede de usar AR e Repository, apesar de que você provavelmente vai fundir Entity e Repository no mesmo objeto -se isto é bom ou não é outra história. Ainda assim não existe qualquer obrigação em Rails de se seguir DDD, aliás a maioria dos projetos Rails que vi não seguem, então qual seu ponto?
Novamente: você está confundindo uma discussão sobre padrões com uma discussão sobre Domain-Driven Design. Não é porque eu não preciso dos padrões clássicos para ter DDD que eu não posso discutir sobre implementações dos padrões.
Dicordo Tarso. Se você vai fazer uma query parametrizada com HQL ela tbm vaio ter os parâmetros, assim como uma EJBQL ou até mesmo uma QueryByExample de sua implementação de QueryObjects. Se você fosse fazer uma pesquisa em uma árvore LDAP, você tbm pode utilizar esta lista de parâmetro cromo critérios da pesquisa.
O título do post é “Agora não há desculpa para não entender DDD”. O artigo está bem focado em DDD e nem tanto em Domain Patterns. Por que essas discussões sempre descambam pra mesma discussão que já falamos aqui mais de 10.000 vezes?
Imagine que você está desenvolvendo uma aplicação baseada em transações no Mainframe. Dentro do mundo de transações você precisa definir quais transações são necessárias para seu sistema. Nesse aspecto sua ubiquitous language pode se basear em “dados de entrada” e “dados de saída” e a transação ser um Service. O escopo da sua aplicação não é o Mainframe, mas sim externalizar isso. Você poderia usar DDD num típico modelo anêmico.
Sorry… foi provocativo mesmo… queria ver respostas de outros aqui… não deu certo. 
[quote=pcalcado]
Novamente: você está confundindo uma discussão sobre padrões com uma discussão sobre Domain-Driven Design. Não é porque eu não preciso dos padrões clássicos para ter DDD que eu não posso discutir sobre implementações dos padrões.[/quote]
O problema é que as literaturas dão exemplos de implementação e não regras de implementação. Tomar os exemplos como regras é uma rigidez conceitual arriscada. Você mesmo concorda que não há CERTO ou ERRADO, eu particularmente não gosto quando dizem “não deve tocar”, “nunca deve depender”, “não é correto”. Algumas pessoas podem errar um padrão por desconhecer, outras podem tomar decisões fugindo da literatura baseadas em risco e benefício.
[quote=rodrigoy]
O problema é que as literaturas dão exemplos de implementação e não regras de implementação. Tomar os exemplos como regras é uma rigidez conceitual arriscada. Você mesmo concorda que não há CERTO ou ERRADO, eu particularmente não gosto quando dizem “não deve tocar”, “nunca deve depender”, “não é correto”. Algumas pessoas podem errar um padrão por desconhecer, outras podem tomar decisões fugindo da literatura baseadas em risco e benefício. [/quote]
Talvez não haja o certo, mas com certeza ha o errado. Desse ponto de vista, o certo é não fazer errado.
Em outras palavras: existem best pratices(melhores práticas) e bad pratices (más práticas). O certo é seguir as melhores práticas e abandonar/não seguir as más práticas. Acho que isso é passivelmente aceitável.
Agora atenda ao nome “melhores práticas”. “prática” aqui, não opoe a teoria, mas significa apenas “experiencia empirica”. Ou seja, de tanto trabalhar com a coisa, as pessoas já descobrir formas mais eficientes de trabalhar com elas ( e também as formas menos eficientes). Isto, acho, também é obvio.
O que tlv não seja tão obvio - tlv nasça a ideia de que ha um certa prepotência nas afimações - é que as melhores práticas podem ser deduzidas de principios primeiros, fundamentais, da OO e de outras áres relacionadas a desenvolvimento ( pro exemplo, melhores práticas de construção de UI não vêm de OO, vêm de disciplinas como a ergonomia e em ultima análise da teoria das cores e da arte).
Deste ponto de vista os principios fundamentais ( como o Principio de Separação de Responsabilidade) são a “melhor teoria” de onde pode ser derivada a melhor prática e a pior prática. Deste ponto de vista sim existe o correto e o errado e são uma única coisa : o nivel de obediencia aos principios fundamentais.
Quanto a pessoa não conhece os principios fundamentais ou não vê como eles se relacionam com outras coisas ( padrões , por exemplo) ela não entende que a autoridade de uma melhor prática advêm de um pensamento, de um principio, e pensa -erradamente- que se trata de uma mera convenção; que as pessoas dicidiram fazer da forma X e fazer da forma X é melhor porque é o que a maioria aceita. Ora, isso não é verdade. A verdade é que se faz da forma X porque a forma X deriva de principios fundamentais. E não se faz da forma Y porque Y é uma violação aos principios fundamentais.
O conhecimento empirico é muito bom, mas é pior que o conhecimento teorico que lhe dá origem. Se uma pessoa tentar decorar todos os principios práticos ela será um bom desenvolvedor se os respeitar; mas se ela souber de onde eles derivam ela não terá que os decorar e poderá derivá-los sempre que necessário e conforme a circunstancia do ambiente onde os necessita.
É esta adapatabilidade que a teoria tem a produzir resultados ligeiramente dirernetes conforme o ambiente que o conhecimento empirico não tem.
Conhecer os principios e derivar as práticas é ciencia. Conhecer as práticas e ingorar os principios é superstição.
Sim existe o certo e sim existe o errado. O errado é não fazer o certo, e o certo é seguir os principios.
Aceite esta permissa básica sobra discutir a imutabilidade dos principios.
Os principios em si são imutáveis. o SoC sempre será o SoC. Mas o conjunto de principios aceites como “matriz primária” podem variar com o tempo e os costumes. Antigamente não se pensava em Objetos. Funções e rotinas eram o que havia de melhor.
Este conjunto de principios que aceitamos como “o conjunto básico” forma aquilo a que se chama o paradigma.
Portanto, paradigmas mudam, mas dentro de um paradigma é possivel estabelecer o que é certo e errado. quando o paradigma mudar, tlv uma acção que era certa vire errada e uma que era errada seja aceite como certa, mas será em outro paradigma.
A literatura simplesmente corre atrás das alterações de paradimga e da documentação das práticas ( boas e más) e da sua relação com os principios básicos. Contudo este é sempre um trabalho em andamento (work in progresss) e nunca pode ser tomada como a palavra final. Nunca.
A literatura serve para nos guiar, não para nos prender.
Sergio, vc varia do pragmatismo à rigidez numa velocidade incrível! Seu post foi muito filosófico e lendo a thread toda fica até confuso interpretar seu ponto de vista. Queria algumas respostas mais diretas suas às questões abaixo.
Já discutimos antes: http://www.guj.com.br/posts/list/90/85211.java
Posts atrás vc mencionou que para implementar DAO corretamente eu preciso de DTOs. Na discussão listada acima você falou que necessariamente a casadinha Repository/DAO necessita ser Strategy. Não quero reviver aquela discussão.
Você diz que os padrões são linguagem e para que eles estejam certos eles devem ser implementados como diz GOF, Fowler, Evans e etc…
Todos os padrões são classificados no tão fadado: Problema, Motivações, Solução, Estrutura e Exemplos. Até o momento você diz que se você não seguir ao menos a Estrutura não podemos dizer que estamos usando o padrão. Se eu tenho um problema (data mapping) que segue as motivações e se aproxima do padrão DAO mas não usa TO você poderia dizer que não estamos usando o padrão? Não poderemos chamar a classe de DAO?
Quando falamos DAO o que deveria vir a nossa mente: o problema e a solução ou a estrutura?
Outro ponto. Pelo que me lembro Core J2EE Patterns não deveria se aplicar a arquitetura mais modernas como EJB3, principalmente no acesso a dados JPA. Certo? Como devemos chamar então as classes que usam o EntityManager?
Pode, vc pode tudo. Dever vc não deve. Se vc não utiliza TO o seu DAO não é independente do dominio/negocio.
Se o seu problema e apenas o data mapping e vc resolve usar entidades como retorno e paramentro vc resolveu o seu problema.
Mas ao fazer isso vc criou outros problemas : dependencia. O que eu estou dizendo é : se quer resolver o problema , use o padrão certo. Se não quer ter mais problemas depois, implemente o padrão da forma certa. E a forma certa é, aquela que segue os principios de OO. Independencia (baixo acoplamento) é um deles.
O que é ou não um DAO tem a haver com: (por ordem de relevancia)
Para descobrir a responsabilidade vc precisa levar em conta outros fatores como o acoplamento, o tratamento de exceções, etc, etc… ou seja, vc precisa aplicar os conceitos e principios de OO.
Depois vc pensa na implementação. Ela é uma consequencia directa do passo 1 portanto é muito simples.
O que não pode ser feito, e é isso que muitos fazem , é começar pela implementação e chutar um nome para o objeto que não é coerente com a sua responsabilidade.
Se vc quer um atalho neste processo vc usa um padrão. Mas, embora existam ajustes que podemos fazer nas implementações do padrões ( por exemplo, um VO serializável é mais util do que um que não seja) o espirito do padrão - as responsabilidades do objeto - têm que ser respietadas. Se isso não acontecer não estamos seguindo o padrão. Estamos sendo inspirados (vagamente) pelo padrão. São coisas diferentes.
Aquilo que o padrão é, está nas responsabilidades dos objetos que ele propõe. Tudo o testo é consequencia directa de OO, de principios ou da sintaxe do java e seus construtos.
A responsabilidade de cada objeto envolvido no padrão.
No caso do DAO existem: a interface publica do DAO, os objetos passados ao DAO para que ele execute pesquisas, os objetos passadas ao DAO para que ele execute edições , os objetos retornados pelo DAO como resultado da consulta,
a implementação do DAO para a tecnologia X, a implementação para tecnologia Y, etc…
Esta coisas têm que ser tais que:
A opção 3 é boa se vc quer o seu DAO reutiliável. Se não quer, ignore-a. Contudo saiba que no proximo projeto vc vai implementar o DAO outra vez…
como vc consegue 2 sem usar objetos de transferencia ?
como vc consegue 2 e 3 sem usar objetos de transferencia ?
O uso de TO é a opção lógica pela simples aplicação dos requisitos do DAO.
Como eu já disse: se não quer ter um DAO reaproveitável utilize as entidades à vontade. (só não se queixe depois 
)
A segunda edição do Core Patterns tem muitas influencias do trabalho do Fowler e do Struts. É um remake, mas tem mais tempo de filme que antes. Algumas cenas foram incluidas como Domain Storage (que é o JPA).
Embora seja uma referencia o livro é muito versado em arquitetura web e ignora quase sempre outras arquiteturas, mas pelo menos para essa tá valendo ( a maior parte )
A arquitetura EJB 3 é apenas uma evolução da 2 onde mais padrões são providos pelo container. Mas o uso e entendimento dos padrões subjacentes é o mesmo. A diferença é que antigamente vc precisa construi-los à mão. Agora vc os tem no conteiner por default. Mas tal como antes tlv o default nao seja suficiente, e nesse caso os padrão ainda têm a sua importancia.
Se não for por mais nada, tem importancia historica e como catalogo.
Repositorio.
Pois é, se o livro que define o padrão chama, por que você não poderia?
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
Quanto as respostas do sergiotaborda, já disse que não perco mais tempo me repetindo e o MarcioDuram, esse ai nem vale a pena.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
[/quote]
Mas essa é a a forma como as coisas evoluem, com questionamentos. Eu acho ótimo que as pessoas tenham idéias diferentes sobre as coisas, que discordem e achem besteira fazer do modo X e Y. O que não dá para engolir é alguém que diz que a sua versão do conceito/coisa é o CERTO e o que o autor do conceito/coisa escreveu é ERRADO. Eles são discordantes, só isso. Da discórdia pode até sair um conceito muito interessante, mas não adianta dizer que esse é o DTO como catalogado por Fowler, este é o DTO como catalogado pelo Joãozinho e ainda que o Joãozinho tenha razão -o que não necessariamente é verdade- ele precisa deixar claro que é um outro ponto de vista sobre o conceito.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
[/quote]
Mas essa é a a forma como as coisas evoluem, com questionamentos. [/quote]
Exatamente. Estou totalmente de acordo com você. O problema todo é:
Isso realmente não dá pra engolir. Dai o motivo de toda irritação.
:idea: Direito de Resposta
Não estou nesse debate sobre DDD, entrentanto eu venho acompanhando o assunto com atenção das pessoas especializadas ou melhor entendida e posicionamento, quanto observadas as suas colocações, é lamentável por só tomar carona em pensamentos alheios, “tenha mais personalidade ou saiba só ouvir quem possa melhor dar explicações.”
Não há desculpa para não entender DDD, eu colocaria com existem milhares de questões a se projetar Patterns, não só se baseando em aspectos de autoria e referências apenas bibliograficas mas sim em requisitos que melhores vão ser projetados em seu Core de responsabilidades.
Eu acho essa frase que o Phillip começou a falar aqui no forum corretíssima. O unico problema é que o pessoal ta se apegando nisso e começando a era do “Vale qualquer coisa já que não tem certo/errado” e distorcendo tudo conforme lhe apraz.
[/quote]
Mas essa é a a forma como as coisas evoluem, com questionamentos. [/quote]
Exatamente. Estou totalmente de acordo com você. O problema todo é:
Isso realmente não dá pra engolir. Dai o motivo de toda irritação.[/quote]
Mas… dizer que o autor errou não é um questionamento ? Não é isso uma evolução ?
Afinal os criticos de Da Vinci , Darwin ,Hamilton, Eisntein , etc devem ser todos amordaçados e deixados sem palavra?
Afinal o submarino, a asa delta , o helicóptero e o avião existem porque alguem leu o trabalho de Da Vinci mas o colocou em causa. Aproveitou a essência e reescreveu a concretização
O mesmo para a moderna teoria da evolução baseada no DNA. ninguém mais dá crédito ao que Darwin escreveu em seus diários, mas a essência do que ele escreveu - que existia uma evolução natural - foi aproveitada. As regras dessa evolução foram reescritas várias vezes ao longo do século. O mesmo para o trabalho de Hamilton sobre Quaterniões: um construto matemático tão poderoso que resume o eletromagnetismo a uma equação (e não 4), mas que, pela sua complexidade não é usado. Mas qualquer matemática os aceita e entende o que é um quaternião e até são usados em animação 3D. O mesmo para o trabalho de Einstein. Todos os que o colocaram em causa encontraram outras formas de ver as coisas. E mesmo com a sua fama e grande contribuição para o conhecimento humano ainda é ridicularizado (infamemente) pela citação errada da frase “Deus não joga aos dados” quando a frase completa é :" Não acredito que o Grande Arquiteto criasse um universo como o da Mecânica Quantica, não acredito que ele jogue os dados"
Isto é para ilustrar a falha em endeusar os autores. Criam-se mitos e inverdades que apenas atrapalham o desenvolvimento do conhecimento com um todo. Autores são pessoas normais, também erram. Não aceitar isso é viver em uma utopia.
Sim, os autores escrevem coisas que vão contra as normas , os modelos , as teorias : os paradigmas subseqüentes, mesmo quando o trabalho deles deu origem a esse paradigma. Pioneiros são mais suscetíveis de ter esses problemas, porque embora tenham tido a inspiração ( insign) que dá origem ao paradigma, nenhum homem é capaz de explorar um novo paradigma sozinho. À media que ele é explorado por outros, e à medida que ha documentação do paradigma, essa documentação está votada a ficar desatualizada em algum tempo. O tempo em que ela permanece válida depende do tempo em que o paradigma permanece inalterado. A idade média na europa viveu um período negro porque muitos se recusavam a abandonar o paradigma teocrático/monárquico que existia. Quando isso aconteceu muitos morreram pela mesma insensatez e irritação que o Emerson diz sentir. Nada bom advém dai. Foram necessários séculos e muito esforço para mudar as coisas.
Podem espernear o quanto quiserem. Rogar quantas pragas quiserem. Ridicularizar o quanto quiserem. Mas nunca será aceitável dizer que um autor é dono da verdade absoluta e o que ele disse ou escreveu é irrevogável, imutável ou indiscutivel. Isso é nada mais, nada menos, que pertencer a uma inquisição e executar censura. Nunca aceitarei participar disso e ninguém neste fórum deveria.
Se ha argumentos, ha argumentos. Se não ha argumentos, é melhor ficar calado. Demonstrações de censura, ataques pessoais, ridicularizações publicas , e todas essas armas comuns de quem vive no passado , preso a texto antigos , são ações completamente vãs e apenas servem para demérito deste forum.
Irrite-se o quanto quiser, mas pelas coisas que valem a pena.
Por outro lado, quem não compreende um simples texto de português não pode ficar irritado com coisa nenhuma até entender o que foi escrito. Análise e síntese, duas ferramentas vitais que infelizmente quase ninguém neste forum sabe usar. Antes de ficarem irritados ou ridicularizarem os participantes , ou até censurarem o que é dito, pensem em utilizar essa ferramentas e entender os assuntos. Enquanto não conseguirem, optem por ficar calados como faz a grande maioria de usuários deste forum. Observar é uma virtude muito melhor que a irritação.
Acho que vou pedir revisão dos pontos perdidos em todas as provas de interpretação de texto que fiz na minha vida, pois afinal de contas, eu tinha o direito de interpretar diferente do professor. Tentar entender a idéia do autor? não faz o menor sentido, melhor ficar com a minha. :shock:
Sobre essa questão de DAOs com DTOs, posso até concordar que o Core J2EE Patterns apresentou o uso daquele em conjunto com este. Mas isso era considerado boa prática quando sistemas J2EE eram modelados em termos de BOs e TOs; hoje em dia, onde somos tão estimulados a manter dados e comportamento em uma só entidade, IMHO não há justificativa em criar TOs apenas para utilizar o DAO da forma como veio ao mundo.