Revista MundoJava edição 28 - Sua Aplicação é Segura?

Gostaria de saber se já foi elaborado um reportagem utilizando hibernete, Spring e JPA na mesma aplicação e de preferências exemplos com mapeamento de tabelas em xml e com annotations na mesma aplicação.
Obrigado.

Vo correr para ver nas bancas, pois, como jah disse em outro tópico, aqui na cidade chega um exemplar para cada banca somente, sendo que nem todas as bancas recebem. hehehehe… froide!

Ola Guerra tenho uma sujestão… seria interesante se a revista abordace algum assunto mais exotico que a maioria não esta acostumado em ver em sites e revistas porai… coisas mais cientificas mas sendo explicada de uma forma mais facil e pratica…
seria interesante algo como: redes neurais, BI, algoritimos geneticos… entre outras coisas mais exoticas cujo seu entendimento so encontra-se em livros com muito embasamento teorico e matematico e pouco pratico seria interesante se tivesse qualquer hora alguma materia que tenha um foco nestes aspectos mas de uma maneira mais pratica e de facil entendimento…

brunotonet:

Gostaria de saber se já foi elaborado um reportagem utilizando hibernete, Spring e JPA na mesma aplicação e de preferências exemplos com mapeamento de tabelas em xml e com annotations na mesma aplicação.
Obrigado.

Esses assunto já foram tratados separadamente, mas não todos em um único artigo.

ja saiu ? hehe nem terminei de ler 100% (80% lido ) da edicao anterior… mais aproveito parabens!!! A ultima edicao está muito show mesmo principalmente a materia Modelagem Ágil… muito show…

Bom guerr@ aproveitar tb para fazer a solicitacao “pesssoalmente” de acrescetar refatoring com um case real ja que ultimamente a revista vem abordagem tecnicas de desenvolvimento ágil…

flw!!

brunotonet:

Gostaria de saber se já foi elaborado um reportagem utilizando hibernete, Spring e JPA na mesma aplicação e de preferências exemplos com mapeamento de tabelas em xml e com annotations na mesma aplicação.
Obrigado.

http://www.mundojava.com.br/NovoSite/adquiraedicoesanteriores.shtml

luistiagos:

Ola Guerra tenho uma sujestão… seria interesante se a revista abordace algum assunto mais exotico que a maioria não esta acostumado em ver em sites e revistas porai… coisas mais cientificas mas sendo explicada de uma forma mais facil e pratica…
seria interesante algo como: redes neurais, BI, algoritimos geneticos… entre outras coisas mais exoticas cujo seu entendimento so encontra-se em livros com muito embasamento teorico e matematico e pouco pratico seria interesante se tivesse qualquer hora alguma materia que tenha um foco nestes aspectos mas de uma maneira mais pratica e de facil entendimento…

A medida do possível a revista vai incluindo alguns tópicos mais acadêmicos, porém com um ponto de vista mais prático. Como exemplos posso citar o artigo sobre JOGL, que falou muito sobre computação gráfica, e o artigo sobre o Weka, que abordou a parte de data mining. O problema é que são tópicos que interessam a poucos, porém a medida que conseguimos pessoas que escrevam sober esses assuntos sob uma perspectiva mais prática (o que geraria o interesse de mais pessoas), pode ter certeza de que incluiremos tópicos desse tipo na revista.

Mais uma edição sem nada interessante.

A cada 11 edições sai uma descente.

É so uma opinição.

Migrei para uma nova empresa e possuo um projeto com hibernate e Spring estava pensando aproveitar o que já tem pronto e desenvolver as coisas novas em JPA ?EBJ? para ganhar produtividade, mas já vi muito post, blog mais todas as alterações que realizei fui mal sucedido.
Talvez alguém possa compartilhar essa experiência.
Muito Obrigado.

Eu gostei do artigo sobre DDD.

Ainda não li os outros artigos.

onolox:

Mais uma edição sem nada interessante.

A cada 11 edições sai uma descente.

É so uma opinição.

Isso depende do nível de quem lê. Pra mim, está interessantíssima essa revista.

djemacao:

onolox:

Mais uma edição sem nada interessante.

A cada 11 edições sai uma descente.

É so uma opinição.

Isso depende do nível de quem lê. Pra mim, está interessantíssima essa revista.

tb concordo!!

onolox:

Mais uma edição sem nada interessante.

A cada 11 edições sai uma descente.

Isso é independente de cada um, não achou interessante o conteúdo da revista, não compre. Ainda sou iniciante, sei fundamentos e alguns frameworks. As vezes fico perdido em alguns artigos, e outros nem leio por falta de interresse, mas em geral, gosto da revista. A revista dá conselhos para quem está buscando certificação SCJP como eu.

Sugestão Guerr@, acho que deveria haver mais artigos sobre os diversos frameworks, vantagens e desvantagens, como por exemplo, estou vendo Tapestry, e acho pouca informação disponivel na net.

Sobre a revista, vou ver se encontro na banca ainda hoje…

Muito bom mesmo o artigo sobre DDD…

Como sugestão espero que na proxima edição tenha uma continuação sobre o DDD explicando os patterns mais utilizados, etc…

É isso ae!

eu gosto muito da revista embora tenha comprado
só uma vez quando apareceu na banca aqui em Minas ela não aparece muito.Eu estou olhando as edições anteriores tem muita coisa sobre SOA .

Legal, estava procurando algo WSS4J. Essa edição pelo menos pode me dar uma luz. :lol:

eles precisam melhorar o sistema de logistica da revista… que ainda estar a desejar… por exemplo a revista chega primeiro na banca que para os assinantes…

Agora olha o que acontece com as outras revistas por exemplo a info… os assinantes recebem a revista no maximo ate o dia 5 de cada mes… normalmente dia 3… e na banca somente apos dia 5,6 de cada mes… Eu realmente to pensando em manter assinatura… ta mais rapido pegar na banca q esperar chegar…

LPJava:

eles precisam melhorar o sistema de logistica da revista… que ainda estar a desejar… por exemplo a revista chega primeiro na banca que para os assinantes…

Agora olha o que acontece com as outras revistas por exemplo a info… os assinantes recebem a revista no maximo ate o dia 5 de cada mes… normalmente dia 3… e na banca somente apos dia 5,6 de cada mes… Eu realmente to pensando em manter assinatura… ta mais rapido pegar na banca q esperar chegar…

Eu cancelei a minha assinatura e agora compro na banca. Assim evito dores de cabeça! :lol:

A revista só chegava em casa um mês depois de chegar na banca. E eu ainda mandava e-mail para o pessoal
de assinaturas, eles falavam um prazo que nunca era cumprido.

Enfim, agora compro na banca e é bem mais tranquilo!

Bom, com certeza devem existir muitas pessoas que recebem a revista na data certa, mas este era o meu caso.

[]'s

lavh:

LPJava:

eles precisam melhorar o sistema de logistica da revista… que ainda estar a desejar… por exemplo a revista chega primeiro na banca que para os assinantes…

Agora olha o que acontece com as outras revistas por exemplo a info… os assinantes recebem a revista no maximo ate o dia 5 de cada mes… normalmente dia 3… e na banca somente apos dia 5,6 de cada mes… Eu realmente to pensando em manter assinatura… ta mais rapido pegar na banca q esperar chegar…

Eu cancelei a minha assinatura e agora compro na banca. Assim evito dores de cabeça! :lol:

A revista só chegava em casa um mês depois de chegar na banca. E eu ainda mandava e-mail para o pessoal
de assinaturas, eles falavam um prazo que nunca era cumprido.

Enfim, agora compro na banca e é bem mais tranquilo!

Bom, com certeza devem existir muitas pessoas que recebem a revista na data certa, mas este era o meu caso.

[]'s

É tb to pensando fazer isso… nao sei se a revista tem parceria com os correios… se nao tiver ta na hora de fazer… pois uma parceria com eles… pode ter certeza que chega dentro do prazo… porem sem parceria… chega dentro do prazo do correio… e nao deles… eheheh

onolox:

Mais uma edição sem nada interessante.

A cada 11 edições sai uma descente.

É so uma opinição.

Não li a revista ainda, mas alguns tópicos parecem bem interessantes. Principalmente o de DDD, que muitos desenvolvedores não conseguem entender o que realmente é isso.

Ótima sugestão do LPjava, exemplos reais de refactoring poderiam aparecer nas próximas edições. E adicionando mais algumas, poderia ter matérias exemplificando outras “siglas” no mundo do desenvolvimento como TDD, DSL, MDD, etc…

marcosbrandao:

Ótima sugestão do LPjava, exemplos reais de refactoring poderiam aparecer nas próximas edições. E adicionando mais algumas, poderia ter matérias exemplificando outras “siglas” no mundo do desenvolvimento como TDD, DSL, MDD, etc…

Não vou adiantar nada, mas podem esperar que as próximas edições trarão novidades a respeito dessas “siglas”!!!

O artigo de DDD continuará nas próximas edições, focando os patterns e outros aspectos do DDD, por exemplo?

MDA também ficou bem legal. Sou um pouco pé atrás com essa sigla, nem li todo o artigo ainda, mas achei legal.

peczenyj:

Eu gostei do artigo sobre DDD.

Ainda não li os outros artigos.

Pena que foi só sobre linguagem omnipresente (ubiquitous language) que nem é uma caracteristica que mais atormenta quem quer usar DDD. Pelo menos a julgar pela quantidade de topicos do guj relativos a isso.

8. A Revista Mundo Java, ela é bem organizada e objetiva em si, os conteúdos são bons, todavia uma questão que ficar à pensar , sobre o profissional consultor Java “ou especialista em aplicações OpenSourcer” é o que, o mesmo vem à enfrenta no mundo Corporativo em que vive, a revista não questiona isso.

:idea: Ela demonstrar soluções e técnica avançadas, mas em vista disso como é encarado nas Empresas este profissional, que mais parece um Gato Felix com a Maleta Mágica nas mãos, com resposta para tudo.

:arrow: Entrevista com profissionais e consultores depoimentos e incertezas sobre o futuro desse profissional, que tanto e técnico como investidor que paradigmas vai se defrontar.Quais as melhores consultorias , melhores empresas onde achar os caminhos das pedras.

Me lembro que a Revista Mundo Java, havia montado um Forúm, talvez em uma forma de questionar artigos e matérias, porém acho que o GUJ foi o que os consultores adotaram para um caminho com a cara do consultor java.

:idea: Temos que buscar o real das questões, acho que a revista esta indo atrás disso, ao menos é o que percebo.

Muito bom o conteudo da revista, gostaria que a materia sobre DDD fosse mais explorada na próxima edição.

sergiotaborda:

Pena que foi só sobre linguagem omnipresente (ubiquitous language) que nem é uma caracteristica que mais atormenta quem quer usar DDD. Pelo menos a julgar pela quantidade de topicos do guj relativos a isso.

Sergio, a conversa com os especialistas de negócio e a ubiquitous language são o cerne da DDD. Os Domain Patterns não são necessariamente DDD. Como falei no artigo, não é porque vc está usando Repositories que necessariamente vc está usando DDD. DDD é mais fora do sistema que dentro dele.

Trabalhar com entidades é possível desde que a OO surgiu. Aggregates é praticamente o mesmo conceito de composição/agregação que tínhamos na OMT/Booch Method (coisinhas de 20 anos atrás, e nem foram eles que inventaram isso, é mais velho ainda). Muito das dúvidas correm sobre Repositories. Simplifique isso! Repositories simplesmente são abstrações do domínio que concentra as buscas do negócio (obter referências que não podem ser obtidas pela navegação numa associação como exemplo).

Um Domain Model e a Ubiquitous Lang. deveriam ser preocupações maiores que as Domain Patterns para quem busca DDD.

Também fiquei com essa mesma expectativa. Espero que o assunto continue.
Aliás, todos os últimos artigos escritos pelo Rodrigo Yoshima foram realmente excepcionais.

marcosbrandao:

… o de DDD, que muitos desenvolvedores não conseguem entender o que realmente é isso.
… poderia ter matérias exemplificando outras “siglas” no mundo do desenvolvimento como TDD, DSL, MDD, etc…

Marcos e outros… pena que não tive tempo de elaborar mais isso, mas nas referências temos exemplos de implementação de DDD no Jboss Seam.

http://www.aspercom.com.br/santapaola

Não está perfeito (esse mês passado foi muito corrido pra mim), mas dá para ter uma boa idéia. As Domain Patterns são simples!!!

Na próxima edição vou falar sobre “o ciclo ágil de 1 dia”, isto é, o dia a dia de um desenvolvedor agilista. Como ele obtem requisitos, como “planeja” a construção de um incremento, TDD, Colec. Code Owner., Pair Programming, Teste de Integração. E mais, teremos a ilustre participação do nosso amigo CV… (isso se ele não se esquecer de me mandar a parte dele até o final do dia).

Queria também agradecer aqui a colaboração do Lezinho e do Shoes para o artigo dessa edição, figurinhas que sempre estão por aqui.

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.

Entendo a falta de tempo, não deve ser fácil.
Parabéns ao artigo e se um dia sobrar mais tempo espero que possa escrever mais sobre o assunto.
Vou aguardar a próxima edição.

Entendo a falta de tempo, não deve ser fácil.
Parabéns ao artigo e se um dia sobrar mais tempo espero que possa escrever mais sobre o assunto.
Vou aguardar a próxima edição.

Digo o mesmo, pois essa matéria foi uma ótima iniciativa e deixou um gostinho de quero mais! Pena eu não ter a mesma proatividade para escrever um artigo como este, Rodrigo. No entanto, fica aqui a manifestação de um leitor que quer ler mais sobre o assunto. O assunto DDD é ao meu ver muito interessante e carece de bons materiais (pelo menos mais didáticos e práticos) mostrando como colocar a bagaça pra funcionar. :mrgreen:

rodrigoy:

sergiotaborda:

Pena que foi só sobre linguagem omnipresente (ubiquitous language) que nem é uma caracteristica que mais atormenta quem quer usar DDD. Pelo menos a julgar pela quantidade de topicos do guj relativos a isso.

Sergio, a conversa com os especialistas de negócio e a ubiquitous language são o cerne da DDD.

O DDD é um subtipo de Model Driven Development. É MDD levando ao extremo por assim dizer.
As mesmas tecnicas de conversa e linguagem são usadas no MDD. A grande diferença é que o DDD
foca tudo no dominio ( que é um subconjunto do modelo) e retira todas as suas conclusões.

O que eu quiz dizer é que a linguagem omnipresente não é uma caracteristica especifica da DDD, não é o que torna a DDD a DDD. Da mesma forma que uma reunião stand-up ou pair programing não formam um processo agil.
Ok, os padrões tb não a formam a DDD. Concordo que porque usa entidades e serviços não significa estar usando DDD. Afinal esses padrões foram introduzidos pelo Fowler em paralelo à DDD.

Se vc tivesse escrito o mesmo artigo e tivesse chamado de MDD ficaria tudo na mesma (excepto a citação do Evans… )

Só acho que essas duas coisas não forma a DDD. são ferramentas da DDD como o pair-programing é do XP.
A bem ou a mal as pessoas entendem isso. Procurar um DM ou uma linguagem são coisas que todo o mundo deveria fazer mesmo antes de existir DDD. O que trava as pessoas é o uso práticos desses conceitos (patterns incluido). E se os conceitos por detrás do padrões não são explicados e entendido não ha diferença entre DDD e MDD com Design Patterns… bem, agora que penso nisso, se calhar não ha mesmo…

rodrigoy:

… o de DDD, que muitos desenvolvedores não conseguem entender o que realmente é isso.
… poderia ter matérias exemplificando outras “siglas” no mundo do desenvolvimento como TDD, DSL, MDD, etc…

:thumbup: Na Edição da Revista Mundo Java nº19 (Reflexão+Anotações) sobre o artigo UML não é documentação, achei que você abriu a mente de muita gente, fora exemplos citados como Tecnicas de User Stories(XP), Features(FDD), Use Case.Tenho acompanho os artigos que você vem divulgando e tem uma aspecto que vem de encontro com as minhas idéias também, acho que é bem por ai mesmo.
Espero que os assuntos de TDD, DSL, MDD venham a ser colocador com todas as desmestificações possíveis.

Sergio, diferente do que você citou sobre as “práticas” utilizadas no XP e que o contempla, os padrões no DDD são apoios e não práticas necessárias.

Você utiliza Factory se precisar (vc poderia utilizar D.I.), utiliza Application Layer se assim fizer necessário (poderia utilizar um framework de abstração para esta camada), utiliza VO para maior flexibilidade do que uma entity desnecessária (mas não é estritamente necessário para a constituição de um DM).

Palavras de Evans sobre Domain-Driven:

Eric Evans:

“
Domain-driven design flows from the premise that the heart of software development is knowledge of the subject matter and finding useful ways of understanding that subject matter. The complexity that we should be tackling is the complexity of the domain itself – not the technical architecture, not the user interface, not even specific features. This means designing everything around our understanding and conception of the most essential concepts of the business and justifying any other development by how it supports that core.”

… foco no conhecimento do domínio e de como espelhar sua complexidade entre “Domain Especialists” e o software, no lugar de se preocupar com arquiteturas técnicas e similares é o core do DDD, por isso a importancia do Ubiquitous sobre qualquer pattern.

Lezinho:

Sergio, diferente do que você citou sobre as “práticas” utilizadas no XP e que o contempla, os padrões no DDD são apoios e não práticas necessárias.

Você utiliza Factory se precisar (vc poderia utilizar D.I.), utiliza Application Layer se assim fizer necessário (poderia utilizar um framework de abstração para esta camada), utiliza VO para maior flexibilidade do que uma entity desnecessária (mas não é estritamente necessário para a constituição de um DM).

Palavras de Evans sobre Domain-Driven:

(…)
… foco no conhecimento do domínio e de como espelhar sua complexidade entre “Domain Especialists” e o software, no lugar de se preocupar com arquiteturas técnicas e similares é o core do DDD, por isso a importancia do Ubiquitous sobre qualquer pattern.

Tudo o que vc falou se aplica a qualquer metodologia de modelagem. Os padrões, quaiquer que sejam, sempre são usados quando necessário. “Domain Especilists” é apenas um nome para algo que sempre existiu. Outras metadologias dão outros nomes: por exemplo “stakeholders”. Não ha nada de novo em ter que falar com pessoas que entendem o dominio. E não ha nada de novo na necessidade de uma linguagem comum. Isso é o dia-a-dia.
Se o mérito da DDD é apenas chamar a atenção para a necessidade dessas coisas… bom, afinal não é muito mérito. É chamar as coisas com nomes bonitos e apresentar o óbvio.

Acho que a diferença fundamental entre a DDD e as outras metodologias de modelagem está no ponto de honra de colocar o desenvolvedor no mesmo patamar que o analista (aliás criando um hibrido). Ou seja, o cara que codifica é o mesmo que conversa com o cliente. Não ha intermediários. Não ha documentação “de tradução”. não ha perda (lost in translation) entre o que cliente “especilista” diz e o que o codigo faz.
Então a importancia do DDD está no facto do codigo também traduzir o dominio. Como diz a citação do Evans do artigo “dominio” é algo abstracto e está presente em muitos lugares de formas diferentes. Mas no fim, o que importa é que as interações entre os bytes mapeiem compreensivelmente as interações entre os atores , entidades e processos do dominio. Logo, a importância do DDD está no codigo ser uma reflexão do dominio. A complexidade da DDD é atingir esse introzamento entre o codigo e o dominio. O artigo parece defender que esse introzamento se limita a dar os nomes certos às classes… isso parece pouco.

Falar de DDD sem falar do codigo é insonso. Todas as outras caracteristias existem em outras modelagens. Ou vai-me dizer que em outras modelagem não se fala com os clientes ? não se cria um modelo ? não se usa uma linguagem comum ? As pessoas podem até estar menos consicentes de que estão fazendo isso, mas fazem.
A filosofia da DDD dá um passo à frente , e parece-me que foi esse passo em frente que não ficou explicito. Não foi dada a importancia necessária ao codigo. E mais, pelas respostas dos colegas do forum dá bem para ver que não ficaram satistifeitos só com aquele blablabla filosofico. O pessoal quer é codigo!

Falar de codigo não significa necessáriamente falar dos padrões , mas a menos que seja uma programação POG os padrões têm que estar lá. O que parece que falta entender é que não ha uma mapeamento 1:1 entre os padrões e as classes. Por exemplo, ninguem vai entender o que é uma entidade sem o conceito de identidade. A DDD diz que o dominio deve ser expresso em codigo. Então a pergunta que todos fazemos é : “Então, como se expressa em codigo ?”

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.

+1! Essa é uma questão bastante comum.

Sérgio,

1. Me cite algum outro autor que falou de linguagem comum que deve ser expressa no código… me diga um autor antes do Evans que falou para “fortalecer essa linguagem”.

2. Nenhuma metodologia diz que o analista não pode programar e nem que programador não pode analisar. Que autor defende essa história do “híbrido”?

Que parte vc sentiu isso?

Jesus…

[size=18]http://www.aspercom.com.br/santapaola
[/size]

Você acessou? Desculpa cara, vc está sendo insolente. Não coloquei o código no artigo porque o artigo não é um HOW-TO isolado. Se eu colocasse o código no artigo ficaria com 40 páginas. O código está nesse link. E tem bastante código, acredite. Logicamente vc vai postar aqui kilos de crítica ao código. Se vc fizer isso vou ser obrigado a te desafiar a escrever um artigo melhor.

O objetivo do artigo era chamar a atenção para outras práticas da DDD que são ofuscadas pelos patterns. E tem outra. A DDD é uma evolução porque hoje temos tecnologia para focar mais o domínio no código. Antigamente isso era possível mas inviável na maioria das vezes (lembra dos datamappers implementados na mão e os infinitos proxies para ter um lazyload?). DDD é novidade porque a tecnologia hoje permite que a gente desenvolva software desse jeito.

Sérgio, primeiro não foi “eu que falei”, vide citação do próprio Evans…
O que você diz sobre interações de desenvolvedores com o cliente é mérito de qualquer metodologia ágil, e não exclusividade do DDD. Tomando a linha de raciocínio de seu post anterior, isto também não é merito de DDD.

Mas o resto do que você falou sobre não perder informações entre o cliente e a codificação, não ter (necessariamente) documentação de tradução, código traduzir o domínio… foi justamente o foco “Ubiquitous” do artigo. Em vista que você mesmo reafirma estes pontos e também concorda que os padrões não são frutos do Domain-Driven (quote abaixo):

sergiotaborda:

(…)Ok, os padrões tb não a formam a DDD. Concordo que porque usa entidades e serviços não significa estar usando DDD. Afinal esses padrões foram introduzidos pelo Fowler em paralelo à DDD.(…)

… eu fico meio sem entender o enfoque que você gostaria. O Shoes já escreveu sobre a maioria dos padrões utilizados em DDD na própria Mundo Java. A leitura do livro Domain-Driven Design, gera tópicos de dezenas de páginas, acho que uma abordagem no estilo “Resumão” de todo o livro, perderia o foco de quem esta lendo sobre o assunto pela primeira vez.

O que eu acho interessante, em todo e qualquer artigo de revistas, é despertar no profissional o interesse em se aprofundar no assunto abordado e não ser um expert em poucas páginas. Por isso a resposta que acho a mais sensata para a pergunta que você fez: “Então, como se expressa em codigo ?” é:

• baixar os fontes do artigo
• http://domaindrivendesign.org/books/
• GUJ :twisted:

Concordo que novas edições sobre o tema poderia ser bom, só não vejo como resumir todo o livro em um artigo. Acredito que a maior relevância, de fato foi abordada.

Rodrigo,

Eu acho que o codigo fonte disponivel para o artigo poderia ter dado mais enfase no dominio explorando outros padroes como demonstracao, mas o exemplo que baixei so continha entities e um DTO.

Espero que considere isso uma critica construtiva porque em relacao ao artigo eu achei muito bom e espero que mais artigos sobre esse tema sejam publicados nas proximas edicoes!

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?

djemacao:

Deixa entender a sua colocação. Você quer dizer em relação a ser mais prático e menos teórico?

Pois é, acho dificil conseguir isso escrevendo um artigo, por melhor que seja o autor…

cmoscoso:

Eu tomei a liberdade de chamar o seu “Value Object mutável” de DTO.
Value Objects são imutáveis.

Como é que você faz isso em Java de maneira simples num contexto persistente? (isso vai virar outra thread!)

:?

cmoscoso:

djemacao:

Deixa entender a sua colocação. Você quer dizer em relação a ser mais prático e menos teórico?

Pois é, acho dificil conseguir isso escrevendo um artigo, por melhor que seja o autor…

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é?

sergiotaborda:

Nem mesmo o codigo de apoio do artigo. É pedir muito ?

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.

peczenyj:

Eu gostei do artigo sobre DDD.

Ainda não li os outros artigos.

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

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

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:

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.

… 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!

Retirando um trecho do livro OO em 21 dias, em português.

Isso mostra, IMHO, que uma linguagem comum é um benefício ao se modelar um bom domínio. Isso foi retirado de um livro de OO, não DDD. Perfeitamente natural que DDD se aprofunde e dê o devido valor a este tema. Esse é ao meu ver o objetivo que ele almeja.

Shoes:

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

Com os conhecimentos que obtive sobre OO apenas, tentei aplicar na vida real e nada. Faltava o como, e ainda falta. Boa partes das respostas das perguntas que eu me fazia encontrei no DDD. Se uma pessoa nunca tentou ao menos aplicar bem os conceitos de OO e AOO, pra que DDD?

Por isso também, em minha opinião, DDD é a volta as origens. É aquele cara que tentou usar OO, apanhou, e viu no DDD um grupo de soluções e sugestões para solucionar problemas comuns. Problemas aqueles que você não resolveu apenas com os bons livros de OO.

Lendo as colocações feitas até aqui mostra claramente que ‘Ubiquitous Language’ tem sua importância e é a mola propulsora. Não faz sentido alguém buscar DDD se nunca antes se questionou da dificuldade em aplicar OO. Por isso, IMHO (nem que Evans queira), DDD não pode ser apenas Ubiquitous Language. Quem chega em DDD é por que questiona o modelo e os padrões de desenvolvimento atual. O cara no mínimo não é iniciante.

Não concordo com essa crítica. Não sei quanto a artigo do yoshi -porque não li- mas Domain Driven Design -o livro- traz técnicas e padrões que só são viáveis com a tecnologia atual. Como falei antes os guias de design antigo presuspunham que você não ia usar o modelo OO criado com a linguagem do domínio na implementação, foi preciso desenvolver melhores tecnologias como isolamento de Camadas e aspectos para que isso fosse viável.

Se você quer algo ligado à uma plataforma específica (.Net, java E, etc.) sugiro:

• POJOs in Action (dá uma pincelada em DDD)
• Applying Domain-Driven Design and Patterns: With Examples in C# and .NET - Tenta aplicar DDD na plataforma .Net com C#

Já estou algum tempo ensaiando para comprar o POJO In Action.

Valeu pelas indicações, Shoes!

Iniciante ou não, o ponto é: como ter o domínio modelado como software numa relação próxima de 1-para-1 hoje em dia? Como implementar a linguagem de domínio?

Eu não li o livro que você indicou mas duvido muito que ele responda perguntas como: o que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?

pcalcado:

Iniciante ou não, o ponto é: como ter o domínio modelado como software numa relação próxima de 1-para-1 hoje em dia? Como implementar a linguagem de domínio?

Eu não li o livro que você indicou mas duvido muito que ele responda perguntas como: o que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?

Acompanhando esta thread, em alguns momentos deu a entender que DDD trata-se de linguagem comum e que isso é suficiente para inciar alguém em DDD. É este o ponto que não concordo. DDD, além de Ubiquitous Language é também a sugestão, idéias e caminho para fazer isso que você citou acima.

O livro que citei certamente não responde as dúvidas que você levantou, mas o que questionei é: Se DDD é criar uma linguagem comum somente, fiquemos com OO e bom senso. Por mais que OO não trate exatamente de linguagem comum, percebe-se nos livros e em boa parte dos professores o interesse por Ubiquitous Language e sua importância. Isso faz com que este assunto não seja uma exclusividade do DDD. Corrija-me se eu estiver errado, mas criar uma linguagem comum não é também um pré-requisito para se estudar DSL?

DDD e DSL não são de certa forma um meio para se atingir este objetivo?

Para mim chegar a uma linguagem comum é o obejtivo. DDD é o *meio que você utilizará para chegar lá.

UPDATED:
Entenda a palavra meio como: técnicas, dicas, experiências e patterns, por exemplo.

Não é ter uma linguagem comum, Thiago, não apenas. É usar a linguagem comum diretamente no seu software.

Desculpe mas com alguns anos estudando metodologias de desenvolvimento OO eu realmente gostaria de saber onde uma pessoa adquire este “bom senso” que você fala. Como falei antes os livros mainstream pré-DDD em sua grande maioria tratam domínio e implementação como coisas diferentes, ninguém respondia como fazer isso funcionar num cenário moderno para uma aplicação de verdade. Evans não inventou o conceito mas o traz algumas boas estratégias para fazê-lo funcionar diretamente no software, sem mapeamentos lógicos (i.e. diagrama de domínio != código-fonte), com a linguagem implementada no código.

Sim, DSL pode servir para isso assim como podem objetos, programação procedural, linguagens funcionais e tudo mais. Não sei onde você quer chegar com a comparação.

Como você falou que não leu o livro recomendo que o faça antes de comentar sobre o mesmo.

Thiago Senna:

Para mim chegar a uma linguagem comum é o obejtivo. DDD é o meio que você utilizará para chegar lá .

UPDATED:
Entenda a palavra meio como: técnicas, dicas, experiências e patterns, por exemplo.

DDD é o lá, e não como chegar… veja meu ultimo post na página anterior e as palavras do autor do livro.
Veja também o link abaixo (que também ja postei), onde Evans dá uma breve descrição sobre MDD e DDD:

http://www.domaindrivendesign.org/discussion/blog/evans_eric_ddd_and_mdd.html

… note que em nenhum momento ele associa DDD com o uso de algum pattern (exceto, claro, uma observação quanto ao perigo de se usar Transaction Script).

Um código retratando o domínio e sua complexidade, lhe fazendo responder rapidamente a mudanças no negócio, isso é DDD, simples assim. Para chegar nisso, o livro sugere patterns e práticas, mas não é só isso, a própria evolução da tecnologia nos da facilidades e complementos para lhe ajudar na construção de um domínio rico e isolado (Aspectos, apis de Injeção e evolução de frameworks que permite isolar o domínio de forma transparente, como o Seam), são ferramentas que podem lhe ajudar a chegar lá.

Se você tiver martelo, prego e madeira você sabe construir um móvel?

A orientação a objetos é a ferramenta e o DDD mostra como utiliza-la!

Muitas pessoas aprendiam os conceitos da orientação a objetos, mas não sabiam como aplica-los. Durante um certo tempo, deu-se muita ênfase na arquitetura e no uso de frameworks, que a modelagem das classes de domínio acabava ficando de lado. Era só tentar utilizar uma herança em classes de dominio utilizando os pesadões Entity Beans para ver a dor de cabeça que dava…

O DDD foi uma sacudida para que os desenvolvedores percebessem que não adianta nada usar vários frameworks excelentes, se a aplicação não resolver os problemas do cliente! A orientação a objetos deve ser utilizada no dominio do cliente e não só para estender as classes dos frameworks.

No fundo, os conceitos da OO e o DDD são conhecimentos muitos valiosos para quem trabalha com modelagem de aplicações. Fique com seus livros de orientação a objetos, mas não ignore o material de DDD, pois se pode aprender muito com ele!

Acho que não é essa a crítica, Eduardo.

O que as pessoas estão dizendo -com razão- é que já se dizia para ter um modelo de objetos na mesma linguagem do mundo real bem antes. O ponto é que Domain-Driven Design trabaha esta linguagem no código e não apenas em modelagem (i.e. diagramas) e num cenário moderno.

pcalcado:

Acho que não é essa a crítica, Eduardo.

O que as pessoas estão dizendo -com razão- é que já se dizia para ter um modelo de objetos na mesma linguagem do mundo real bem antes. O ponto é que Domain-Driven Design trabaha esta linguagem no código e não apenas em modelagem (i.e. diagramas) e num cenário moderno.

Na minha opinião, o que o DDD trouxe de novidade foi trazer essas técnicas de orientação a objetos para esse cenário mais atual, pois muitas pessoas viam as técnicas de identificação de classes mais antigas e olhavam para a arquitetura da aplicação e as coisas não “casavam”…

PS: Quando me referi a modelagem, eu não quis dizer apenas a criação de diagramas, mas a modelagem no sentido da estrutura das classes, independente de estarem representadas em um diagrama ou em código. Exemplo: refatoração é uma atividade de modelagem que trabalha direto com o código.

Não concordo com isso. As abordagens antigas são plenamente “casáveis” com qualquer plataorma OO que eu conheça (mesmo as nao class-based ou as não baseadas em trocas de mensagens), o ponto é que requer um conhecimento grande transformar as idéias ali em código implementável, e isso não foi estimulado nas últimas décadas.

Guerr@:

PS: Quando me referi a modelagem, eu não quis dizer apenas a criação de diagramas, mas a modelagem no sentido da estrutura das classes, independente de estarem representadas em um diagrama ou em código. Exemplo: refatoração é uma atividade de modelagem que trabalha direto com o código.

Sim, é isso que estamos discutindo neste tópico. Se você ler algumas mensagens anteriores vai enteder o porque de ter vincuado modelagem com diagramas nas metodologias clássicas/antigas.

Com certeza! De exemplo posso citar os cartões CRC, que foram deixados meio de lado, mas que hoje voltaram a toda nas metodologias ágeis! O problema realmente é a habilidade das pessoas em fazer isso. O que estava querendo dizer é que eu vi em muitos projetos os desenvolvedores focando muito em frameworks e arquiteturas, e esquecendo da OO no coração da aplicação: nas classes de dominio.

:thumbup: Pela primeira vez que eu concordo com você !!!

SwingBean, é o resgate dos paradigmas da Orientação a Objetos ?

Opa… olá a todos. Não é que o assunto chegou até a segunda-feira?

Bom, já falei aqui o objetivo do artigo era chamar a atenção para DDD e dizer que os padrões não são a DDD propriamente dita. Uma das coisas que mais gostei na contribuição do Phillip para a revista foi “os padrões são simplesmente soluções de caixinha”.

Antes de mais nada, as questões do Sergio precisam de resposta, certo? Algumas coisas já devem estar claras para vocês. Um VO não necessariamente precisa se imutável, e no caso de um VO Endereço existem grandes razões para que ele não seja imutável e a maior delas é a simplicidade.

Basicamente, é exatamente contra esse tipo de “colocação” ou sentimento que pretendí combater no artigo. É a RIGIDEZ CONCEITUAL. Meu repository está aqui:

interface GenericRepository<T> {  
	       
     public T getById(Long id);  
	       
     public List<T> getAll();  

     public List<T> getAll(String orderBy);  
	       
     public void remove(T instance);  

     public void save(T instance);  
	   
} 

public interface GradeCurricularItemRepository extends GenericRepository<GradeCurricularItem>{

	public abstract List<GradeCurricularItem> get(Professor professor,
			Horario horario);

	public abstract List<GradeCurricularItem> get(String sala, Horario horario);

}

Códigos não interessantes para a discussão foram retirados. As perguntas são:

1. Essa abstração não me diz exatamente que o repositório seria um armazenamento puro e simples?

2. Não está bem separado o que o repositório supostamente deve fazer?

3. O conhecimento do domínio não está embutido nesse código? (seriam as buscas necessárias para o sistema funcionar)

4. Aonde você está vendo dependência de JPA, Hibernate ou qualquer outra tecnologia de infra?

Bom, essa INTERFACE é o repositório e não a implementação DAO. Podemos dizer que essa interface é onde eu concentro o conhecimento DDD. Esse é o elemento que podemos discutir juntamente com os usuários. O DAO depende de infra (implementação), o repositório (abstração) não.

Continuo defendendo que é um assunto que não dá pra levar como ciência exata e nem com receitinhas de bolo. Isso é defendido por muitos autores (o eterno engodo de procurar a bala de prata). Você pode falar o que for, mas qualquer hype que sofremos seria muito mais religião do que ciência exata. Isso porque trabalhamos na maioria das vezes baseados em tendências. Dá pra saber o que o mercado vai querer amanhã? Posso ter usado um termo errado, talvez determinismo é muito forte para o que quiz dizer. Usei essa palavra mais no sentido que não existe uma receitinha de bolo. Minha implementação de repository é só uma alternativa entre muitas existentes e não existe nenhuma 100% correta, isso é muito relativo.

De qualquer forma, a mensagem é NÃO SE APEGUE A RIGIDEZ CONCEITUAL. O mercado está cada vez mais buscando pragmatismos, veja Scrum, XP, Spring, EJB3, Dave Thomas, Ruby/Rails, DSLs (ao invés de MDA), Lean/Agile e a própria DDD. Não siga as coisas ao pé da letra.

Marcio Duran:

Guerr@:

O que estava querendo dizer é que eu vi em muitos projetos os desenvolvedores focando muito em frameworks e arquiteturas, e esquecendo da OO no coração da aplicação: nas classes de dominio.

SwingBean, é o resgate dos paradigmas da Orientação a Objetos ?

O problema é esquecer da OO nas classes de domínio, e não utilizar os frameworks. O problema é que um foco muito grande nos frameworks acabava por tirar o foco de um parte importante.

Já que você perguntou, não sei se conhece o SwingBean ou se já utilizou ele em algum projeto (se não conhece aproveite a oportunidade e acesse http://swingbean.sf.net ). O SwingBean utiliza metadados das classes de domínio para montar formulários e tabelas. Dessa forma, os componentes de interface interagem direto com as classes da aplicação criando um foco maior nas classes de domínio. Respondendo sua pergunta, o SwingBean não é o resgate de um paradigma, mas ele simplifica a camada de interface tornando-a mais “íntima” dos objetos da aplicação. Com isso, os desenvolvedores podem se preocupar mais com as classes de domínio da aplicação do que com a construção de telas.

:evil: :evil: :evil:

To achando que esse tópico chega a 10 páginas… :twisted:
Mas Yoshi, como vc colocou o Shoes e o Lezinho como “EU USO”, não seria legal escolher alguem “EU NÃO USO” pra discutir as diferenças?!? Acho que com cada um defendendo seus os pontos de vista daria uma visão maior pra galera que está acompanhando suas matérias!
E, apesar de concordar que DDD e DDD Patterns são coisas que podem viver tranquilamente separadas, acho, tambem, que vc deveria escrever mais um artigo como DDD Patterns e como aplica-los no mundo real…

rodrigoallemand:

Mas Yoshi, como vc colocou o Shoes e o Lezinho como “EU USO”, não seria legal escolher alguem “EU NÃO USO” pra discutir as diferenças?!?

Quando alguém escreve um artigo, raramente se fala sobre a experiência pessoal na utilização da técnica/tecnologia/etc… que é o tema do artigo. A idéia do EU USO é mostrar no formato de depoimento, a opinião de pessoas que já utilizaram com sucesso o que está se falando no artigo. Na edição sobre MDA e Modelagem Ágil, foram colocadas experiências com os dois tipos de abordagem.

Um EU NÃO USO é complicado pois muitas vezes a pessoa simplesmente prefere outra abordagem, mas não tem coisas contra e nem conhece direito o que está sendo falado. Seria como colocar alguém para dar um depoimento sobre o RUP em um artigo sobre XP. Aí acho que não faz muito sentido…

Concordo… mas existem pessoas com conhecimento em DDD (por exemplo) e que não são “tão a favor” desta abordagem por acharem que em nem todos os casos o DDD é válido… não falo de projetos simples ou complexos… acho que DDD não depende de complexidade… mas existem projetos que o DDD só enrola a maneira mais simples de fazer… Vcs (MJ) são formadores de opinião, isso é fato! Muitos iniciantes são guiados pelas matérias que vcs publicam. E eles precisam saber que o DDD não é o último biscoito do pacote!

Rodrigo, logicamente que vou escrever mais um artigo com DDD Patterns a pedido de vocês, apesar do Shoes já ter escrito sobre isso. Talvez faça com Spring e Hibernate (uma infra mais leve que o Seam para simplificar). Vou conversar com o nosso amigo Guerra a respeito para o artigo de Julho (pena que vai demorar).

De qualquer forma, o artigo desta edição não é de forma alguma “blá blá blá filosófico” como colocaram aqui. :? Conceituei Domain Model, dei exemplos práticos de erros na Ubiquitous Language, falei sobre mudanças que podem ocorrer no processo de desenvolvimento e até escreví sobre o COMO, através da apresentação do estudo de caso “Santa Paola”, em complemento ao código. E de fato, para a DDD esse é o mais importante, por mais paixão/dúvidas que vocês tenham pelo lado bits-bytes.

Que tal publicar em um blog ou algo do gênero. Pode fazer isto em poucos dias e com pouco trabalho

Se não nos apegarmos aos significados e aos conceitos e às suas representações reais seria uma bagunça inumerável e ninguem se entenderia.
Se eu apresentar isto

object.method(otherobject)

e lhe disser que é uma estrutura de repetição vc não vai acreditar em mim. Vc esperaria algo como

while (condition){
  //do something
}

Mas se eu escrever isto:

component.accept(visitor)

Tlv vc aceite, porque os nomes foram escolhidos a dedo. E se vc tiver o mesmo conceito que eu, e estiver usando a mema nomenclatura é simples de aceitar.
Mas se isso não é suficiente (não será para 80% das pessoas) vc tem que explicar o que está em causa ali. Aquilo é uma das partes do padrão Visitor.
E agora sim, poderemos discutir se o padrão visitor implementa ou não uma estrutura de repetição.
E não importa o que mais ninguem disse sobre essa afirmação.

Não é aceitável que se aceite que a informática é baseada em crenças, opiniões, hypes, etc… tecnologia pode até ser assim, mas ideias não são tecnologia. Ideias são ideias. As aceitamos ou rejeitamos. As desenvolvemos.
Não interessa quantos hypes ha por ai, todos dizem a mesma coisa. Todos fogem do mecanismo rigido em que o software é feito como um prédio ou uma ponte. Acho que é obvio neste momento que software não é engenharia civil. Então não vamos bater mais em teclas de pianos antigos. Queremos dar um passo em frente.

Se realmente DDD não tem nada a ver com patterns não escreva mais sobre isso. Não se deixe cair na tentação do que o publico quer. Mas se afinal os conceitos não são para ser levados à risca e é aceitável vc escrever um artigo sobre os patterns DDD não vejo porque razão não é aceitável dizer que os padrões fazem parte da DDD.
São um corolário das ideias vinculadas por um modelo e linguagem omnipresente.

Se não quiser dar esse passo a mais , tudo bem. Continue ligado à rigidez dos livros , autores e citações que conhece a abandone a ideia de que os patterns têm alguma coisa a ver com DDD. Isto não é uma religião. Ninguem o força a aceitar as ideias com base na fé.
O que não lhe é permitido é ter dois pesos e duas medidas. Ou bem que se é rigido e se aceita que DDD não tem nada a ver com patterns, e portanto não presta nenhum guia para construir código( embora peça que o modelo de dominio seja traduzido em codigo. Isso é uma antitese. É mais ou menos como o médico lhe dizer que tem que cuidar da saude, mas não lhe explicar como) Ou bem que se aceita que ha espaço para manobra e não ha uma rigidez absolutas das teorias e filosofias associadas ao DDD. Caso em que, podemos muito bem evoluir o DDD para a associação de padrões e codigo e dizer que o padrões fazem parte sim da DDD. ( supondo que não faziam antes)

Como eu acho que ha espaço para evoluir e como não me apego a livros (biblias?) e citações eu prefiro associar os padrões com a DDD. (Crufiquem-me, mas eu gosto de explicar como a pessoa pode tratar da saude, em vez de apenas dizer que tem que a tratar. )

Então a conclusão é a seguinte:
A)Se a teoria da DDD inclue os padrões no seu nucleo, temos que entender como eles entregam a promessa de construir um modelo de dominio com codigo.
B)Se a teoria da DDD não inclui os padrões no seu nucleo , ela é inutil pois não explicar como entregar a promessa de construir um modelo de dominio com codigo.

Em qualquer dos casos o artigo está incompleto sem explicar como a promessa de construir um modelo de dominio com codigo é alcançada. Com ou sem falar em padrões.

Apresentar codigo pronto não é igual a explicar. É como dizer que as piramides são possiveis e colocar um foto delas. Isso não explicar como elas foram construidas.

A minha resalva ao artigo era apenas essa: gostaria de ler uma explicação de como construir um modelo de dominio com codigo.

Mas como vc mesmo falou, uma só explicação não é suficiente. Uma só visão de um so caso de exemplo, não é suficiente. É verdade. Concordo com vc, é melhor não ter nenhum. E neste caso entendo porque o artigo termina onde termina e não penso que ele está incompleto.

Obrigado pelo dialogo.

P.S.
Mas mesmo assim eu vou continuar procurar como se traduz o modelo de dominio em codigo.

sergiotaborda:

A minha resalva ao artigo era apenas essa: gostaria de ler uma explicação de como construir um modelo de dominio com codigo.

Mas como vc mesmo falou, uma só explicação não é suficiente. Uma só visão de um so caso de exemplo, não é suficiente. É verdade. Concordo com vc, é melhor não ter nenhum. E neste caso entendo porque o artigo termina onde termina e não penso que ele está incompleto.

P.S.
Mas mesmo assim eu vou continuar procurar como se traduz o modelo de dominio em codigo.

[quote=pcalcado]Iniciante ou não, o ponto é: como ter o domínio modelado como software numa relação próxima de 1-para-1 hoje em dia? Como implementar a linguagem de domínio?

Eu não li o livro que você indicou mas duvido muito que ele responda perguntas como: o que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?[/quote

Sergio,

DDD é algo mais amplo, compreende a UBIQUITOUS LANGUAGE e MODEL-DRIVEN-DESIGN.

Os padroes pertencem ao segundo e o artigo da revista focou no primeiro.

Concordo… mas existem pessoas com conhecimento em DDD (por exemplo) e que não são “tão a favor” desta abordagem por acharem que em nem todos os casos o DDD é válido… não falo de projetos simples ou complexos… acho que DDD não depende de complexidade… mas existem projetos que o DDD só enrola a maneira mais simples de fazer… Vcs (MJ) são formadores de opinião, isso é fato! Muitos iniciantes são guiados pelas matérias que vcs publicam. E eles precisam saber que o DDD não é o último biscoito do pacote!

Normalmente, quando a pessoa não utiliza alguma coisa, normalmente não o faz porque prefere utilizar uma outra abordagem. Se você conhecer alguém que queira escrever um artigo sobre alguma outra técnica que julga ser melhor, mostrando os problemas e as deficiências do DDD, por favor, peça para essa pessoa entrar em contato comigo. Porém, não me agrada muito a idéia de um artigo que só critica uma abordagem, sem mostrar um forma melhor de fazer!

Quer apostar? :twisted:

Quer apostar? :twisted:

Se o livro em questão é o OO em 21 dias, é bem provavel que você vai perder a aposta! Nem de persistência ele fala! rsrs

Rodrigo, não leve a mal minha inquietação. Não sei se posso concordar com essa sua afirmação. Você está dizendo para não seguirmos algumas coisas ao pé da letra, tudo bem. Mas em muitas discussões que rolaram aqui no GUJ recomendavam que o repositório deveria parecer mais com uma collection, utilizando por exemplo add ao invés de save.

IMHO, ao usar save ao invés de add seu repositório fica meio ‘data base driven’. Pra alguém falar que isso ai é um DAO não custa muito. Daí a importância de que algumas coisas seriam melhores se fossem ao pé da letra.

Que fique bem claro que não estou dizendo que seu repositório é um DAO. Entendi sua explicação. Nem quero que esta discussão vire DAO x Repository. Sairia completamente do foco. Resumidamente, IMO usar repository.save ao invés de repository.add afeta a qualidade da comunicação e isso me faz questionar se devemos ou não ser rigidos na hora de explicar e ensinar algum novo conceito.

Quer apostar? :twisted:
Olá Alessandro.
As palavras que vc citou acima não são minhas, estas pertencem ao Phillip Calçado argumentando com o Thiago Senna.
Creio que houve uma pequena confusão, e de fato o livro não responde as perguntas.

Mandei mal agora … eles falavam do OO em 21 dias e eu pensei que foi um post seu se referindo ao Domain-Driven Design book.
:?

(Ronildo, você deveria ter aceitado a aposta… e só depois esclarecido, hehe)

Vão ter quantas partes esse resumo? Alguem sabe?

rsrsrsrs na próxima eu não irei perdoar

Voltando ao assunto, acredito que vc tenha lido o livro do DDD, portanto qual a abordagem do livro para responder as peguntas: O que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?

Sei que o pattern repository ajuda, mas isto é suficiente ?

Sergio, nem sempre padrões são explícitos. A API de InputStreams do Java é baseada em Decorators, nem por isso há menção clara a respeito disso, senão, chamaria BufferedOutputStreamDecorator. Muito da API do Swing é baseada em Observers e nem por isso consta em qualquer lugar que tal padrão é utilizado. Padrões são só soluções comuns. Um Visitor não precisa estar necessariamente implementado dessa maneira e com esses nomes para ser um Visitor.

Concordo com alguns autores que defendem que padrões são mais importantes pelo aspecto didático. Na maioria das vezes trabalhamos gerenciando dependências de olho em coesão, acoplamento e complexidade. A partir do momento que você conhece bem e já aplica OO, você não pensa mais nos padrões. Eles se tornam naturais. O pensamento é “vou desacoplar isso” e não “vou usar o padrão Strategy” (eu mesmo costumo esquecer o nome dos padrões) :?

É exatamente isso! As aceitamos ou as rejeitamos. Aceitamos e rejeitamos baseados em quê? Em crença na maioria das vezes. Nós lemos os livros do Ambler, Fowler, Schwaber, Beck, GOF, Três Amigos por que? Basicamente porque acreditamos neles. Muitos deles dizem: “-Olha, minha técnica não é 100% garantida que funciona, depende de um monte de coisa”. Isso é uma ciência exata? Não. Se não é, muita intuição está em jogo. Na maioria das vezes seguimos as práticas simplesmente porque elas nos fazem sentido e já erramos anteriormente. Não temos certeza que elas funcionam, nunca trabalhamos em nenhum projeto com esses caras e nem sabemos se eles realmente tiveram sucesso na aplicação dessas técnicas. Como vc pode ver, a questão é complexa.

O software, como qualquer outro produto do meio criativo é uma idéia [não me lembro direito que autor falou isso].

Se eu não escrever o que o público quer, vou escrever sobre o quê? E outra, nenhum momento disse que os padrões DDD não são importantes. Eles são! Só que na minha visão, eles são fáceis na tecnologia atual se você parar com frescura e picuínhas. Essa rigidez conceitual que existe (ainda) na comunidade Java é exatamente o que fez muita gente engolir EJB goela abaixo sem se questionar muito (mais uma decisão baseada em crença para alguns: “-Se a Sun está dizendo que é assim, eles devem estar certos.” (não digo que isso está certo).

Não entendí o que vc quis dizer com isso.

Que momento eu disse que os patterns não são importantes? Escreví o artigo focado em Domain Model e Ubiquitous Language (o cerne da DDD), fiz o código baseado em Padrões que já discutimos aqui. E creio que o Value Object e o Repository estão claros. O código está sim refletindo o dominio. Aonde está a antitese? O que você está pedindo é outra coisa. Você quer saber o que passou pela minha cabeça quando o cliente solicitava as coisas e aloquei responsabilidades às classes. Bom, as figuras 5 e 6 mostram um pouco isso. As figuras 1 e 2 mostram o anti-pattern. Se você não gostou do artigo porque não foquei mais nisso, paciência.

Estamos fundamentados na alternativa A desde o começo. Os padrões são importantes, mas, Domain Model e Ubiquitous Language são mais. É possível aplicar DDD em sistemas que não são baseados em objetos. Nesse caso, os padrões não são aplicados, mas não deixa de ser DDD.

Mais uma vez. O código está lá. Os padrões estão lá. As figuras 5 e 6 estão lá. E mais, o artigo do Shoes citado também existe.

Ok. O artigo não foi perfeito nesse ponto. Mas, paciência. Fica para um próximo. Mais uma vez vou repetir. A parte técnica da DDD é fácil para a maioria dos sistemas. As tecnologias atuais ajudam muito. As pessoas tendem a complicar coisas que são simples. Compreender o real domínio da aplicação, estabelecer uma abstração de um domain model e fortalecer a ubiquitous language são mais difíceis.

Thiago Senna:

Rodrigo, não leve a mal minha inquietação. Não sei se posso concordar com essa sua afirmação. Você está dizendo para não seguirmos algumas coisas ao pé da letra, tudo bem. Mas em muitas discussões que rolaram aqui no GUJ recomendavam que o repositório deveria parecer mais com uma collection, utilizando por exemplo add ao invés de save.

IMHO, ao usar save ao invés de add seu repositório fica meio ‘data base driven’. Pra alguém falar que isso ai é um DAO não custa muito. Daí a importância de que algumas coisas seriam melhores se fossem ao pé da letra.

Que fique bem claro que não estou dizendo que seu repositório é um DAO. Entendi sua explicação. Nem quero que esta discussão vire DAO x Repository. Sairia completamente do foco. Resumidamente, IMO usar repository.save ao invés de repository.add afeta a qualidade da comunicação e isso me faz questionar se devemos ou não ser rigidos na hora de explicar e ensinar algum novo conceito.

Thiago, isso foi proposital. Sabia que alguém iria comentar isso. Sim, a abstração de um repository é uma collection. Porém, pense do lado da Ubiquitous Language e Domain Model. Imagine que nosso domain model seja o próprio código, ou um diagrama de classe da UML revertido 1:1 do código. O repository vai estar com a operação save(Entidade). Você não vê que é uma rigidez conceitual dizer que tem que ser add(Entidade)?

Para a Ubiquitous Language isso é irrelevante. Simplesmente vou falar para o usuário. Tá vendo o Repositório de GradeCurricularItem? É naquela operação save que estará a regra de “um professor não pode estar em duas salas ao mesmo tempo” e “uma sala não pode ser ocupada por duas aulas ao mesmo tempo”. O usuário não sabe o que é uma collection, para ele, tanto faz.

Pode ser uma frescura nossa, do lado técnico, dizer que tem que ser add porque é uma collection. Vejo que o repositório é bom para:

1. Concentrar as buscas
2. Alocar as regras de existência da entidade (estado que a entidade deve estar para entrar no repositório, como exemplo, validações que fogem ao escopo do mecanismo de persistência, tem exemplo no código, como as próprias regras acima citadas).
3. Desacoplar uma associação [um pouco mais raro]
4. Atualização em lote
5. Deixar tudo isso acima claro para os especilistas de negócio [se meu domain model é o próprio código]

O fato é que a tecnlogia que usamos hoje (JPA, Hibernate) tem dificuldades para validar o estado quando as entidades sofrem atualização, e muitas aplicações nós ainda usamos o merge. Mais uma vez acho isso frescura e mito que se criou. Aliás, pode chamar de DAO, pode chamar do que quiser, não vou me ofender (agora, chamar o @Embeddable de DTO isso sim me ofendeu). O cerne da questão é que é saudável ter uma abstração para concentrar as 5 coisas que coloquei acima.

Não sei porque tanta ofensa dizer que o Repository é Database-Driven. Ele é mesmo! 99% das vezes um repository está fazendo alguma coisa num banco de dados relacional. Se podemos abstrair ao máximo tudo bem, mas não vou cortar os pulsos se precisar usar um merge. Prefiro prezar pela simplicidade do que a rigidez conceitual.

:thumbup:Seja como for, estamos criando maturidade para um próximo artigo da Revista Mundo Java, uma coisa poderia até servir de prática, ter o GUJ como um julrado e contestador das melhores idéias.O que nos permitiria uma participação mais efetiva e menos publicitária, dando melhor conteúdo, status e credibilidade, para seu público, nada mais que os seus assinantes.

:idea:Uma idéia, antes da publicação ao referente artigo, fazer uma teste de mesa ao assunto, o GUJ tem essa capacidade, o que pode ser útil e de grande vália.Feito isso os melhores temas teriam uma votação por uma enquete sugerida pela comunidade e a revista as publicaria.

:thumbup:Vamos refatorar melhor nossas Idéias.

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…

rodrigoy:

sergiotaborda:

Se não nos apegarmos aos significados e aos conceitos e às suas representações reais seria uma bagunça inumerável e ninguem se entenderia.
Tlv vc aceite, porque os nomes foram escolhidos a dedo. E se vc tiver o mesmo conceito que eu, e estiver usando a mema nomenclatura é simples de aceitar…

Sergio, nem sempre padrões são explícitos. A API de InputStreams do Java é baseada em Decorators, nem por isso há menção clara a respeito disso, senão, chamaria BufferedOutputStreamDecorator. Muito da API do Swing é baseada em Observers e nem por isso consta em qualquer lugar que tal padrão é utilizado. Padrões são só soluções comuns. Um Visitor não precisa estar necessariamente implementado dessa maneira e com esses nomes para ser um Visitor.

Mas eu não lhe mostrei nenhuma implementação. “visitor” é o nome da variável. Para vc escrever o que escreveu acima é porque vc conhece o padrão. Por isso que o padrão é importante. Padrões são linguagem.
E esse era o ponto. O padrão só é util na medida que é entendido e implementado corretamente. Se uma dessas coisas falha, não ha padrão. Os DDD paterns são importantes porque são uma linguagem. Se vc quiser pensar recursivamente os DDD Paterns são a linguagem omnipresente da propria DDD. Entender e implementar esses padrões corretamente é usar DDD corretamente da mesma forma que implementar Cliente da forma correta é implementar o dominio de forma correta.

Não! Esse pensamento é completamente absurdo! Eu não leio Eisntein porque acredito nele. Eu leio para saber a opinião dele ( sublinho :opinião) e ficar a par do assunto que ele discute. Outros discutem o mesmo assunto sob o ponto de vista das opiniões deles. Etc… É pela sobreposição das opiniões que se entender o que o assunto é.
No fim , essa conversa toda tem que virar algo real, que funciona, que é utilizado.
Afirmar que se lê Fowler ou outro qq porque se acredita nele … putz não tenho palavras para dizer o quanto isso é absurdo!

Se aceitássemos nisso teria que aceitar que eu leio seus artigos porque acredito em si. O que não é verdade. Eu não acredito. apenas isto já mostra que as pessoas leiem as coisas de outras por muitos motivos, mas crença não é um deles.

Não ha uma relação de crença ou crédito quando se lê alguma coisa.
Após a leitura a pessoa tem a sua propria opinião e pode concordar ou discordar do que leu … mas “acreditar” não é um verbo que se aplica.

O problema é que isso não é verdade. Se fosse assim tão facil não existiriam inumeros topicos no guj e em outros lugares falando do assunto.
Existem dois fatores aqui:

1. A pessoa se ilude que entendeu os padrões e que qualquer porcaria pode ser entendida como a implementação do padrão. Ou seja, o padrão é apenas uma ideia.
2. A pessoa estuda o padrão e não consegue entender como o aplicar na vida real. Ou seja, o padrão é um conjunto de regras bem definidas que levam a um propósito explicito. Não são apenas ideias, são artefatos.

O que vc está defendendo é que o padrão é apenas um ideia (1). Reposiorio é apenas um qualquer objeto com qualquer interface que medie entre o dominio e o banco.
Eu não vejo assim. Repositorio NÂO é isso! :evil: Da mesma forma que Singleton não é apenas um factory que cospe sempre o mesmo objeto. O padrão existe por si mesmo. Aplicá-lo é que é a dificuldade.
è claro que o padrão não nasce se eu chamar “XXX” à classe, nem morre se eu nao chamar.

O exemplo do thiago é relevante. Repositorios não têm save. Pela simples razão que não estão ligados a persistencia. É isso que muitos ainda não entenderam. Repositorio não serve para persistir! ( Putz, é muito simples entender isso. Para vc que acredita no Fowler, basta ler que ele se refere a dois padrões: DataMapper e Repository. DataMapper é o DAO e o Repositorio não é o DataMapper, logo, não é o DAO)

É o conceito de Repository que está em causa. O seu conceito. No seu conceito (no de outros tb) Repository ter um add(), save() , persist(), sum() , retain() é tudo a mesma coisa. No nosso não é. Os nomes são importantes. A linguagem do padrão é importante. Ela é feita para ser seguida da mesma forma que a ubiquos language é feita para ser seguida. Padrão tb são linguagem. Tem que existir o mesmo respeito pelos nomes e conceitos dos padrões que ha pela ubiquos language para dominios. Caso contrário a comunicação é futil. Cada um dirá o que entender. Se chão-comum ninguem se entende. ( Veja o numero de topicos que falar de DTO mas chamar VO, coisa que ninguem chama à anos.)

não é aceitável que se identifique o padrão VO com o DTO ou o Repositorio com o DAO. Repositorio não é um DataMapper nem é um DAO. Ele não tem nada ver com persistencia. A persistencia é uma , eu disse uma , das possiveis estratégias para a implementaçãodo repositorio. É uma decisão tecnologica, não é uma decisão de design/arquitetura. O DAO é uma das estratégias (padrão strategy) do repositorio.

class Repository {

     private RepositoryStrategy;

     public Collection find(QueryObject q)
}


class DAOStrategy implements RepositoryStrategy{
 
     private DAO dao;

}

class HashMapStrategy implements RepositoryStrategy{}

(os nomes das classes são padrões , e não classes per se)

Repare no numero de niveis que separam o DAO do repositorio.
Esta mesma logica se poderia aplicar a outros padrões que vc diz ter implementado. Se não ha um seguimento correto dos padroes, então não é possivel afirmar que os implementámos. Padrões são coisas reais. são artefactos. Pessoas diferentes vendo o mesmo codigo vão saber que é o mesmo padrão.Até um algoritmo pode saber isso. É deterministico. Ou está bem feito, ou não está feito. Não existe “padrões semi-implementados” ou “esta classe é uma simplificação do padrão XXX”. Isso é POG. Puro e simples.

Sergio… OK… “concorda ou não concorda”, isso ocorre, e muitas vezes. Mas quais são os termos para vc concordar ou não? É determinista? Dê um exemplo de um autor que você não concorda.

Vc é apegado a rigidez conceitual eu não sou… Cara, na boa? Desenvolver software com você deve ser meio caro. :? 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). Olhe o meu código e olhe o seu: qual deles é mais conciso em passar a idéia que estou querendo concentrar uma coleção de objetos? E pra que usar Strategy? Que cenário você enxerga que a implementação do repositório vai mudar em Runtime? (isso é um requisito apocalíptico :twisted: ).

O problema que vejo é que essa sua visão puritana das coisas acaba tornando as coisas inviáveis. Se tiver essa visão muito rígida nem DDD, nem TDD, nem XP, nem BDD, nem Scrum funciona. É conjunto de práticas. É EMPÍRICO.

É engraçado, vc diz que não “acredita” nas obras, mas sim “quer só saber a opinião”. OK? Se é assim, porque diz que devemos seguir à risca o que consta nessas obras? (nomes, conceitos, estruturas e etc…) E mais, que autor defende que devemos ter essa rigidez, principalmente com relação aos padrões?

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.

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.

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.

Abraço.

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

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:

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

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

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

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.

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]

Veja o que ele escolhe!

Naturalmente para a Corporação as coisas sejam mais políticas do que propriamente técnicas …

Os maiores clientes da ThoughtWorks são bancos. Num dos nosos eventos o diretor de um desses grandes clientes falou:

Bem interessante

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…

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!

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.

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!

parece bacana, vou comprar :!:

Oi Sérgio.

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.

O que você acha?

tnaires:

Oi Sérgio.

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?

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.

DDD:

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.

Entendo.

Para minha camada de aplicação persistir um objeto de domínio, ela tem duas alternativas:

• chamar diretamente a infra (DAO, Session, EntityManager, escambau);
• chamar repositorio.add(), que apenas delega para os DataMappers indicados acima.

De acordo com Evans. a segunda alternativa é perfeitamente aceitável né?

Sim. Há, inclusive, um diagrama mostrando exatamente isso.