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: DDD desde a publicação do Livro de Evans
Postado por Ricardo Almeida em 24 Mar 2009
No evento QCon London 2009, Evans comenta que nos cinco anos após a publicação de seu Livro, ele aplicou em vários clientes, e continua aprendendo o que funciona, o que não funciona, e como conceitualizar e descrever tudo isso. Ele tem adquirido perspectivas e aprendeu muito com o aumento de profissionais experientes em DDD que tem surgido.
Os Slides da apresentação estão disponíveis aqui.
Eric Evans exibe um Mapa Mundial e reflete sobre o modelo e uma linguagem comum de negócios que poderia ser usada no mundo técnico, para facilitar a colaboração e comunicação no projeto. Em seguida Evans comentou o que é Domain-Driven Design e seus principais conceitos.
"DDD é para o entendimento do domínio, e pessoas técnicas poderem conversar com experts no domínio. DDD é sobre a complexidade no domínio."
Model é um sistema de abstração que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas.
Ubiquitous Language é uma linguagem estruturada dentro do domain model e usado por todos membros do time para melhorar a comunicação.
O que é essencial?
- Colaboração criativa dos experts do domínio e experts em software.
- Exploração e experimentação. Podem surgir idéias ruins, porém a exploração desse domínio é muito importante para um bom compreendimento do domínio.
- Modelos emergentes de elaboração e re-elaboração de uma ubiquitous language.
- Camadas explícitas de contextos.
- Foco no principal domínio (Core Domain) .
O que Evans aprendeu sobre Building Block em DDD.
Services, entities, value, objects, factories, repositories são super enfatizados. Eles são importantes mas não essenciais. Value Objects tendem a ser negligenciados. Apesar disso Evans apresenta um novo building block, chamado Domain Events. Ele descreveu esse como "algo que acontece que experts no domínio devem se preocupar".
Sobre Agregates, Evans diz que é o mais difícil de aplicar. É uma camada de consistência para transações, distribuição e concorrência.
O que Evans aprendeu sobre Design Estratégico
- Context Mapping.
- Destilação do Core Domain.
- Estrutura de Larga-Escala.
Context Mapping
Sempre existem muitos modelos e precisamos de um mapa para tradução desses modelos. Um ponto interessante é que trabalhar por um longo período em um domínio não faz de você um expert no domínio.
Context: Qual palavra ou declaração que determina o significado de algo.
Bounded Context: Uma descrição de um de uma condição o qual um modelo particular se aplica.
Context Mapping passo a passo:
- Quais modelos conhecemos? (Desenhe cada um de dê nomes)
- Onde cada um se aplica? (Defina camadas in palavras)
- Onde é a troca de informação? (Desenhe conexões)
- Qual é o relacionamento?
Estratégia:
- Desenhe um context map.
- Trabalhe com líderança de negócio para definir o Core Domain.
- Modele uma plataforma que suporte trabalhar com o Core Domain.
- Trabalhe com gerenciamento para dar liberdade para a plataforma de contexto do Core Domain.
- Desenvolver e modelar no Core Domain.
O que Evans aprendeu sobre DDD e SOA
- A interface de serviço deve ser definida em algum contexto.
- Internos também, mas não frequentemente no mesmo contexto.
- A interface de serviço pode ser definida em um context boundary.
Considerações Finais
- Modelagens precisas são frágeis
- Técnicas de Modelagem sofisticadas são gastas em uma bola de lama.
- É necessário uma camada "anti-corrupção".
- Nem tudo de um grande sistema será bem modelado
Nenhum comentário
Acompanhar Discussão Responder