DTO!!! Se vc achar um DTO nesse modelo eu me mato. :?
Ué… pelas minhas contas são
1 Aplication Service (Façade)
9 Entidades/Aggregates
1 Value Object
5 Repositorios
1 Classe de Teste
Cara, me fala desse DTO que vc achou que até fiquei curioso… (não se apegue ao empacotamento)
Eu tomei a liberdade de chamar o seu “Value Object mutável” de DTO. 
Value Objects são imutáveis.
Na minha mensagem original eu sublinhei o como. Eu me referia a explicar como, não a mostrar como.
O codigo pode ser lindo mas é um exemplo. Eu me referia a mostrar o caminho, a logica, de como partir do dominio e chegar no codigo de forma que o codigo ainda expresse o dominio. Apresentar o resultado dessa viagem é melhor que nada, mas não é tão bom quanto a viajem em si.
No resto eu concordo não ha como explicar tudo num artigo só. Nem é isso que se pede. Da mesma forma que outros queriam ler sobe os patterns eu gostaria de ler mais sobre essa viajem que falei. É só isso.
Realmente ha que despertar o interesse e por isso acho que o artigo poderia seguir uma linha mais interessante e menos enfadonha que falar sobre linguagem omnipresente e todas as outras coisas que podemos ler - e concerteza já lemos - em muitos outros lugares.
Deixa entender a sua colocação. Você quer dizer em relação a ser mais prático e menos teórico?
[quote=djemacao]
Deixa entender a sua colocação. Você quer dizer em relação a ser mais prático e menos teórico?[/quote]
Pois é, acho dificil conseguir isso escrevendo um artigo, por melhor que seja o autor…
[quote=cmoscoso]
Eu tomei a liberdade de chamar o seu “Value Object mutável” de DTO.
Value Objects são imutáveis.[/quote]
Como é que você faz isso em Java de maneira simples num contexto persistente? (isso vai virar outra thread!)
:? 
[quote=cmoscoso][quote=djemacao]
Deixa entender a sua colocação. Você quer dizer em relação a ser mais prático e menos teórico?[/quote]
Pois é, acho dificil conseguir isso escrevendo um artigo, por melhor que seja o autor…[/quote]
Só se fizer uma série de artigos, mesmo porque, se quiser escrever num só, passaria batido em diversas coisas, o que acarretaria num péssimo artigo.
Não. A como se vai da teoria para a prática.
ficaria satisfeito ao menos com a menção ao assunto. Não precisa muito. Bastaria dizer que a DDD acenta em 3 pilares: Modelo do Dominio, Linguagem Omnipresente, codificação com base na linguagem que traduz o modelo.
Explicando cada um e no referente ao codigo dizer as escolhas que foram feitas como "Usei um DTO em vez de um VO porque não descobri como num contexto persistente fazer isso em Java de maneira simples"
Tlv muitos outros tiveram o mesmo problema e querem saber o que esteve por detrás da escolha. Afinal é coerente com DDD usar VO mutáveis só por que ha persistencia ? é coerente com DDD fazer DAO herdar de repositorios ? Afinal qual é a diferença ? Baseado em quê se coloca essa diferença ? É util implementar duas interfaces só para aparecer o nome “repository” no codigo ? etc etc… ou seja, coisa que já discutimos no GUJ várias vezes e para as quais ainda não temos uma resposta. Nem mesmo o codigo de apoio do artigo. É pedir muito ?
Bom, começou né… bem, é tempo de páscoa… não vou brigar com ninguém hoje!
[size=18]Não é um DTO, é um Value Object SIM…[/size] o fato de ser imutável o Evans só falou isso com relação a mudar instâncias por completo, sem misturar. O exemplo dele é claro. MEU Endereco CONTINUA SENDO UM VALUE OBJECT (não tem identidade e descreve um valor e não uma referência). A JPA me garante que um embeddable não vai se misturar com outro. Não preciso ligar pra isso, mas como os gujeiros são chatos, agora estão chamando os @Embeddable de DTOs, logo logo mais alguém vem aqui e dá uma paulada mais forte em vocês…
Eu não vou fazer isso pois é vespera de Páscoa, mas se o assunto se estender até segunda… :twisted:
Opa, sergio, quem tá filosofando agora é você! A questão é mais ampla. Não quero que meus domain objects se poluam com a infra. Particularmente me questiono se a abstração do EntityManager é infra ou não. De qualquer forma, modelar um repositório como uma interface em Java é uma boa opção para se beneficiar de DI. Poderia não ser um DAO, mas um RepositoryImpl… não faz diferença nenhuma… preciso de uma implementação que faça as buscas no EntityManager.
Bom, se eu não fizesse as duas interfaces alguém aqui “tomaria a liberdade” de chamar meus repositórios de DAOs né?
[quote=sergiotaborda]
Nem mesmo o codigo de apoio do artigo. É pedir muito ?[/quote]
As questões levantadas não podem ser resolvidas de maneira determinista. Todo mundo está procurando receitinhas de bolo, mas quando alguém arrisca e dá às caras com uma sugestão vem um montão de gente despejando uma montanha de críticas… Pois bem, o assunto é para pensar e não para seguir alguém. Se eu escrevesse esse passo a passo seria “a maneira que o Yoshi faz”, pode não ser o melhor para vocês. Eu não quero que vocês sigam só o meu exemplo…
Anotando propriedades você evita ter de criar metodos settters num é mesmo?
Você tem razão, eles podem ser mutaveis, mas em casos muito especiais, geralmente ambientes bem específicos como clustering. A regra geral, principalmente para os iniciantes, é tornar seus Value Objects imutáveis.
Bom, esse é seu ponto de vista Sérgio… a pluralidade que você termina seu post (em itálico) é vaga. Esse é o primeiro artigo que conheço em revistas nacionais explorando o tema e acredito que o approach do Yoshi foi certeiro para a ocasião. A matéria não é direcionada para todos aqueles que já estudam, leram ou utilizam o DDD, é apenas a ponta do Iceberg para quem esta tendo o primeiro contato com este tipo de design (o que faz sentido para qualquer possível cronologia sobre o assunto).
O principal detalhes que mostra que não ha uma separação clara entre o dao e o repositorio é que na classe dao existe criação de critérios de pesquisa.Essa criação deveria estar no repositorio e ser passada ao dao e não o inverso.
Implementar um repositorio “the DDD way” não é a mesma coisa que criar um DAO. Esta diferença, para começo de conversa já dá pano para mangas. (O DAO é uma mapeador, o Repository não ) Mas ignorando o DAO por um momento e focando apenas o conceito do repositorio também não é simples. O tipo de conversa que se encontra na net sobre isto é tipicamente igual a esta.
Todo o mundo entendeu que o Repositório funciona como se estivessemos consultando objeto na memoria, mas todo o mundo se esquece de como e porquê isso é feito.
O objetivo de usar repositorio, para começar , é isolar o dominio da construção de queries que dependam do mecanismo de mapeamento. A memoria é apenas mais um mecanismo. DAO é outro. Hibernate é outro, e assim vai. No momento que esses papeis não são bem separados não ha DDD envolvida no assunto já que não-seguir esse padrão é o que todo o mundo faz. Todo o mundo cria o DAO e depois cria consultas SQL na mão e passa como parametro para o DAO. Alguns usam Hibernate e criam Criterias. Dá no mesmo. Criteria do hibernate é um objeto de infra, não de dominio. Logo, nenhum dos objetos do dominio deveria depender de Criteria. O repositorio serve exactamente para isolar isso. Se não ha esse isolamento, o padrão não está sendo usado. Mesmo que os objetos se chamem QualquerCoisaRepository.
Mostrar o codigo, com classes (ou interfaces: não interessa) chamadas Repository não explica porquê o repositorio é necessário, nem como o implementar. Como já falei, é o como que interessa. Mas sem haver um porquê ele é inutil. O mesmo se aplica aos outros padrões.
O VO é outro exemplo claro. Se o objeto contém um modificador isso automáticamente o torna alguma outra coisa que não um VO. Pode ser util ter objetos desses. Nada contra. O problema é chamá-los de “VO do DDD”. Não interessa se a infra vai mágicamente tornar o objeto num ser permutável entre objetos de entidade. O que interessa é que do ponto de vista do dominio o objeto é mutável, não garantido - do ponto de vista do dominio- que ele é um VO. VO têm que ser sem identidade e imutáveis. Sem isso o padrão não existe. É apenas um objeto POJO qualquer.
Claro que podem. Que eu saiba informática ainda é parte da ciencia e não da religião.
Podem existir várias formas de atingir o mesmo conceito, o ponto é atingi-lo.
Se ninguem consegue atingir o ponto deterministicamente o conceito do DDD é falho pois demonstra uma filosofia impraticável. Ai entramos no campo da crença, da subjetividade, da preferencia: da religião
Mais vale desistir se as questões não podem ser resolvidas deterministicamente.
Ninguém nasceu ontem. Se ha um debate é porque já houve muito pensamento por detrás das palavras. Quando alguém dá a cara e avança uma sugestão é necessário que existam criticas. As criticas nascem da curiosidade e do interesse das pessoas. Se ninguem critica não é porque é bom, é porque ninguem entendeu ou ninguem tá-nem-aí para o assunto. Analise critica é sempre bom. É debatendo as escolhas e analizando o entendimento dos conceitos que chegaremos na receita de bolo. (A Relatividade Geral de Einstein tem mais de 100 anos e é criticada até hoje.) Existem receitas que não funcionam. O passo inicial é saber distinguir as que não funcionam, nem tanto encontrar a que funciona.
Existe muitas formas de escrever classes. Poderiamos usar Object, String e List em todo o lugar e mesmo assim obter um sistema funcional. O ponto é seguir a DDD só para fazer um dominio e ter uma linguagem ? Bom, se é , então estamos satisfeitos. Mesmo antes de conhecer DDD eu tinhas essas coisas. Ou o ponto é dar esse passo a mais e tornar o codigo um “modelo executável” ? Sim, queremos um modelo executável. Como eu distingo um modelo executável de apenas código executando ? O que torna um conjunto de classes um modelo executável DDD-friendly ? Os nomes ? os padrões ? a ausência de infra no dominio ? a compreensão simples do codigo ?
Ou melhor, o que impede um aglomerado de codigo de ser um modelo executável ? A falta de padrões ? o incorreto uso/implementação do padrões ? a falta de nomes claros ? A falta de mapeamento entre classes e artefactos do dominio ? (espero que entendam que estas são perguntas retóricas)
Se não existem esses marcadores que fazem a diferença DDD é um embuste. É como dizer “Povo, criem um modelo de classes, usem os nomes do modelo de analise nas classes e sejam felizes” Ora! isso já se faz. É só isso ? Se é só isso me avisem para não perder mais tempo com DDD.
A mim, pessoalmente, parece-me que não é só isso. Mesmo que seja, acho que ha um passo a mais que podemos dar. Se a DDD não vai nesse caminho, paciência. A questão é que esse passo a mais parece mais interessante que o resto. Ao mesmos é algo novo. Mas porque é tão complexo de alcançar ? Vale a pena queimar as pestanas com isso ? Não será melhor continuar com os nossos modelos pseudo-DDD-like e sermos felizes em vez de procurar entender o que seria um real modelo DDD ? (estas não são tão retóricas assim … )
É impressionante como se consegue complicar um conceito simples.
DomainDriven Design é sobre formar a linguagem do modelo e implementar isso em software. Para fazer isso é necessário usar algumas técnicas que isolam a complexidade técnica do domínio, por isso usamos coisas como repositórios e anti-corruption layers, islando o que modela o domínio do que é código de suporte. O livro traz algumas destas técnicas na forma de padrões.
E sobre mutabilidade de VOs:
Value Objects são idealmente imutáveis mas podem ser mutáveis.
[quote=peczenyj]Eu gostei do artigo sobre DDD.
Ainda não li os outros artigos.[/quote]
2…
Na capa da revista, lacrada:
Como eu ia saber que isso era pra iniciante?
Na faculdade, nas aulas de Análise OO já se falava em Ubiquitous Language, só que com outro nome ou misturado à outras idéias e expressões do professor. A importância disso já é conhecida e é um assunto digno de ser martelado, repetido. Se DDD é isso, fico apenas com os bons livros de OO. Enfim, não vejo importância em DDD caso ele não sugerisse patterns de como resolver problemas comuns.
É exactamente isso. Faço minhas as tuas palavras.
Afinal parece que DDD é só conversa. É um hype.
Os caras passam páginas falando de padrões mas quando aperta eles gritam “não! tudo se resume a linguagem” , “vcs podem alterar os padrões do vosso jeito” , “estamos só conversando numa linguagem comum” …
Inaceitável… que perca de tempo! Concordo com vc. Venham os bons livros de OO!
Gente, com certeza deve estar havendo má interpretação de vocês, embora eu ainda não tenha lido a revista.
Thiago, quem disse que Domain-Driven Design é algo novo em si? Pelo contrário, Domain-Driven Design é propagandeado como “de volta às origens da OO”. Eu sinceramente não entendo o que você esperava.
Ainda assim, note que “os bons livros de OO” não precisam seguir a mesma linha. Orientação a Objetos te dá ferramentas, Não te diz como fazer. Se você alum dia já ouviu dizer que Orientação a Objetos foi criada para representar melhor o mundo real 'mentira, isso oi algo pensado depois. OO surgiu porque Alan Kay acreditava que essa era a única maneira de escalar um sistema em performance e complexidade.
De qualquer forma, eu realmente gostaria que você me msotrasse um “bom livro de OO” tão prático. Os "bons livros de OO"geralmente possuem um conjunto de regras de ato nível e quando alguém vai implementar usando suas remissas acaba criando um diagrama de domínio (um “modelo de análise”) com um modelo que parece o mundo real e implementando uma coisa completamente diferente. Eric Evans fala sobre isso:
O Livro é sobre a linguagem e traz padrões que ajudam a criar a linguagem dentro do seu software. Os “bons livros de OO” que você achar não vão conseguir dar muita ajuda nisso simplesmete porque na época que foram escritos a tecnoloia não permitia muita firula. As pessoas criavam seus diagramas com o dmínio bonitinhoe depois tinham que se virar ara mapear aqueles conceitos no códio, usando ponteiros, bases de dados hierárquicas e até linguagens não orientadas a objetos.
Novamente: se você espera algo completamente novo desculpe te decepcionar. Se você espera ajuda para usar boas práticas ese é um ótimo livro.
Thiago e sergio,
se DDD é hype, estranho, isso já dura a 20 anos de acordo com o próprio prefácio do livro. A importancia de um modelo fluente, isolamento do domínio e a linguagem em comum é o que Eric Evans chama de Domain-Driven Design e não um aglomerado de padrões. Se é isto que se ensina na faculdade (domínio rico)… ótimo… mas não é isso que se vê nos projetos corporativos, daí a importancia remanecente da abordagem deste assunto.
Os padrões (nada autênticos (factories, repositories, etc)) foram introduzindos para ajudar que os 3 ítens que citei fossem alcançados, mas não são eles a essência do que o autor chama de “Filosofia Domain-Driven” (e não uma metodologia).
[quote=Prefacio Domain-Driven Design]
Leading softwares designers have recognized domain modeling and design as critical topic for at least 20 years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been formulated clearly, a philosophy has emerged as an undercurrent in the object community, a philosophy I call Domain-Driven Design[/quote]
Como já disse, meu projeto não deixa de ser DDD se no lugar de factories eu utilizar D.I. com Strategies ou meus VOs serem mutáveis, não é isso que faz o design não ser dirigido ao domínio, apenas não estou utilizando as dicas do Evans ou do Fowler.
Na contra-capa do mesmo livro, você tem os termos técnicos do DDD, expostos com índices para suas páginas , interligados por balões e uma barra horizontal… barra esta com apenas dois balões em seu meio - “Ubiquitous Language” e “Model-Driven Design” (o Suple Design). Na periferia desta barra se encontra os padrões.
O artigo apoiou exatamente esta trilha horizontal do DDD, que é o seu cerne. Não que o conteúdo não apresentado na publicação seja de irrelevância, mas mostrar padrões no lugar de apresentar do que se trata a priori do Domain-Driven, não faz sentido algum.
Em http://domaindrivendesign.org/ isso também é reforçado. Domain-Driven Design NÃO É UMA METODOLOGIA, é apenas uma forma de pensar (por isso Eric a chama de filosofia) para acelerar projetos de softwares com complicados domínios:
[quote=http://domaindrivendesign.org/]
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.[/quote]
… se não é uma metodologia, ser metódico quanto aos padrões não convém.
Claro que para atingir este objetivo, como em qualquer design de softwares é necessário utilizar princípios, técnicas e patterns. Geralmente, se utiliza aquelas propostas por Eric Evans em seu livro, foco do site domain-driven:
… mas isso não é pré-requisito DDD.
Pelo que estou entendendo a critica é por acrescentar a essa filosofia de 20 anos mas nao dar um exemplo pratico mais elaborado do uso da tecnologia atual para implementar uma idéia tao antiga.
Fica aí uma sugestao para o proximo artigo na série!