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.
[quote=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.[/quote]
Já tinha notado que DDD não é novidade. Também digo por aí que DDD é a volta às origens. O que espero e vejo no DDD é ‘o como fazer’, ou pelo menos o caminho.
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:
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=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]
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.
[quote=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. [/quote]
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:
… 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!
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.
[quote=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.[/quote]
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.
[quote=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.[/quote]
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.
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:
Essa abstração não me diz exatamente que o repositório seria um armazenamento puro e simples?
Não está bem separado o que o repositório supostamente deve fazer?
O conhecimento do domínio não está embutido nesse código? (seriam as buscas necessárias para o sistema funcionar)
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.
[quote=Marcio Duran][quote=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.
[/quote]
SwingBean, é o resgate dos paradigmas da Orientação a Objetos ?[/quote]
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.
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…
[quote=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?!? [/quote]
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…
