Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
QCon London 2009: Um Exemplo completo de DDD
Postado por Ricardo Almeida em 25 Mar 2009
Peter Backlund e Patrik Fredriksson estiveram no evento QCon London 2009, e falaram sobre DDD mostrando um exemplo completo com uma tecnologia atual.
Eles começaram com uma frase bem famosa do Eric Evans
"A complexidade crítica de muitos projetos de software está no entendimento do próprio domínio"
O maior desafio está na transferência de conhecimento entre as pessoas.
Domain-Driven Design
É a maneira de aproximar os problemas da complexidade de software através da cooperação próxima entre desenvolvedores e experts no domínio (domain). A complexidade está no domínio. Usamos modelos para manipular o domínio.
Model
Um sistema de abstrações que descrevem aspectos selecionados de um domínio e pode ser usado para resolver problemas relatados a esse domínio.
Ubiquitous Language
É uma linguagem estruturada dentro do domain model e usado por todos membros do time para melhorar a comunicação.
A modelagem acontece com um design iterativo
Mas para que serve o DDD para mim? Para um product owner pode significar entregas sem surpresas, alta produtividade, alta qualidade. Para um desenvolvedor pode significar um melhor entendimento para fazer melhores decisões, melhor manipulação das mudanças e foco no que é importante. Para Experts no domínio pode significar uma comunicação mais fácil sem termos técnicos.
Construindo blocos de um Model-Driven Design
* Entities: Distingue pela sua identidade, ao invés de seus atributos. É mutável. Tem um ciclo de vida interessante.
* Value Objects: Definidos somente por seus atributos, não pela identidade. É imutável. Não tem um ciclo de vida interessante.
* Services: "As vezes, não é uma coisa"... e sim serviços.
* Aggregates: Grupo de entidades e value objects com camadas definidas.
* Repositories: Abstração de armazenamento de dados. Suporta buscas e armazenamentos de objetos. Para objetos que precisam de um acesso global, tipicamente um Aggregate Root.
Exemplo: DDDSample
Essa aplicação de exemplo tem vários usos:
* Um exemplo "how to" para implementação de uma típica aplicação DDD
* Suporte para discussão e práticas de implementação
* Laboratório para experimentos controlados.
Tecnologia
* Frameworks e componentes baseados em Open Source
* Bom suporte para DDD e OO.
* Java 6
* Spring Core/ORM/JEE/Web
* Hibernate
* ActiveMQ JMS
* Apache CXF Web Services
* Jakarta Commons
* Maven
DTO in DDD?!
por
Ari Garcia
Enviado
Re: DTO in DDD?!
por
anderson freitas
Enviado
-
A menos que tenha me referenciado errado, e se tiver vou aprender mais agora, falava-se que em DDD objetos "burros", assim definido por Fowler, não deveriam existir, diferente do que vi no exemplo.Poderia me explicar melhor a essência disto?!
Quanto a arquitetura, acredito que realmente ficou muito bem definida!
Vamos as discussões!! Obrigado! -
No exemplo, os DTO's foram criados para fazer a conversão entre as entidades do domínio e a camada de persistencia.
Neste caso, seu único uso é o proposto pelo próprio Pattern DTO (Data Transfer Objects), ou seja, seu ciclo de vida é apenas durante o transporte de valores para (no caso) o 'armazenamento'.
Objetos anêmicos são condenados quando percorrem por todo o sistema, deixando de lado alguns conceitos primordiais da OO. Como exemplo, os muito comuns objetos get/set.
No caso aplicado, foi uma boa escolha para fazer o 'assembler' (onde são utilizados, e apenas lá) o uso dos DTO's.
2 comentários
Acompanhar Discussão Responder