Metodologias Ágeis de Desenvolvimento (Locaweb)

No ano passado, durante a QCON, participamos de um tutorial sobre Domain Driven Design com Ralph Johnson. Pra quem não sabe, Ralph é um dos 4 do GOF (Gang of Four), que escreveu um dos livros mais famosos do mundo de Orientação a Objetos, Padrões de Projetos (ou Design Patterns).  Nesse tutorial aprendemos muito sobre o assunto e começamos a estudar a fundo, com o objetivo de aplicar os conceitos no desenvolvimento dos nossos produtos.

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage,  uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software usando técnicas de Orientação a Objetos. O seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um certo contexto(1), um problema(2) e uma solução(3)

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk.  Quando se fala em Orientação a Objetos, pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas essência de Orientação a Objetos também tem coisas como:

• Alinhamento do código com o negócio
• Favorecimento de reutilização
• Mínimo de acoplamento
• Independência da Tecnologia

Todas essas coisas são bem exemplificadas e mostradas na forma de vários padrões em DDD. Mas o livro também mostra muitos padrões que não dizem respeito a código ou modelagem. Aparecem coisas que estão mais ligadas a processos (como Integração Contínua) ou a formas de relacionamento entre times que fazem parte do desenvolvimento de um sistema complexo.

Eric Evans dividiu o livro em quatro partes:

1 - Colocando o modelo de domínio para funcionar

Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua. Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código. Isso significa que, se durante uma conversa com um cliente do sistema de cobrança, por exemplo, ele disser: “Temos que emitir a fatura para o cliente antes da data limite“, vamos tem no nosso código alguma coisa do tipo

• uma classe para a entidade Cliente
• uma classe para a entidade Fatura
  
• Algum serviço que tenha um método emitir
• algum atributo que chame data limite

Essa linguagem ubíqua deve ser compreendida por todos e não podem haver ambigüidades. Toda vez que alguém perceber que um determinado conceito do domínio possui várias palavras que o represente, essa pessoa deve tentar readequar tanto a linguagem falada e escrita, quanto o código.

Outra forma de colocar o modelo para funcionar é utilizando Model Driven Design (MDD), conforme explicado no vídeo abaixo:

2 - Blocos de construção do Model Driven Design (MDD)

O Model Driven Design possuí vários Padrões, que são os blocos de construção que fazem a representação do modelo abstrato. Esses blocos podem ser:

• Entidades - classes de objetos que necessitam de uma identidade
• Objetos de Valores - objetos que só carregam valores, mas que não possuem distinção de identidade
• Agregados - conjuntos de Entidades ou Objetos de Valores que são encapsulados numa única classe
• Fábricas - classes responsáveis pela criação de Agregados ou Objetos de Valores
• Serviços - classes que contém lógica de negócio que não pertence à nenhuma Entidade ou  Objetos de Valores
• Repositórios - classes responsáveis por administrar o ciclo de vida dos outros objetos e de prover, alterar, e eliminar instâncias destes
• Módulos - abstrações que têm por objetivos agrupar classes por um determinado conceito do domínio

3 - Refatorando para compreender profundamente o modelo

Depois de elaborar um modelo de dados que reflete o seu domínio, usando os blocos de construção do MDD, o processo de aperfeiçoamento do modelo continua. O modelo deve ser refatorado na medida em que se compreende mais e mais novos conceitos do domínio. Muitas vezes alguns conceitos do domínio estão implícitos no código. Nosso trabalho é tentar identificar esse conceitos implícitos e torná-los explícitos. Alguns padrões podem ajudar a compreender mais profundamente o modelo:

• Interface de Intenção Revelada - usar nomes de métodos ou classes que dizem exatamente o que essas classes e métodos fazem, mas não como elas fazem. Dizer como quebra o encapsulamento.
• Funções sem Efeitos-Colaterais - tentar deixar o código com o maior número possível de métodos que não alteram o estado dos objetos, concentrando esse tipo de operação (alteração de estado) em Comandos.
• Asserções - para os Comandos que alteram estados, criar testes de unidade, ou colocar asserções no código que validem, após a chamada dos comandos, as alterações de estado esperadas.
  

  

4 - Projeto estratégico

Além de ter uma Linguagem Ubíqua, usada na elaboração de um modelo consistente e adequado para o domínio, precisamos de algumas estratégias para lidar com sistemas complexos, onde vários pedaços de softwares (desenvolvidos por vários times) interagem entre si. Precisamos delimitar em que contexto cada time trabalha e qual será o grau de interação entre esses times e esses contextos. Para isso os padrões:

• Contexto delimitado - um traçado perfeito sobre o que pertence e o que não pertence a um contexto
• Mapa entre Contextos - uma forma de documentar claramente termos usados para um mesmo conceito em vários contextos (p. ex. no contexto do sistema de cobrança usamos o termo “Fatura”, que significa a mesma coisa que o termo “Nota Fiscal” no contexto do sistema de faturamento)



• Núcleo Compartilhado - Quando dois times alteram uma mesma base de código em comum
• Produtor-Consumidor - Quando os times possuem uma relação bem clara de Cliente-Fornecedor
• Conformista - Caso não seja possível alterar ou pedir alterações  de uma parte do sistema mantida por outro time

• Camada Anti-corrupção - quando temos um sistema legado, com código muito bagunçado e uma interface complexa, e estamos escrevendo um sistema novo com o código razoavelmente bem feito, criamos uma camada entre esses dois sistemas. O nosso sistema novo e bem feito falará com essa camada, que possui uma interface bem feita. E a camada anti-corrupção é responsável por traduzir e adaptar as chamadas para o sistema legado, usando uma fachada interna.

Conclusões

Estes são apenas alguns padrões de Domain Driven Design. A razão pela qual falamos desse assunto no Blog Ágil é que desenvolvimento de software ágil está muito ligado a boas práticas de Orientação a Objetos e outros padrões de comunicação entre sistemas contidos no livro do Eric Evans. Obviamente não é possível entender DDD apenas lendo esse artigo. Nós, da Locaweb, estamos estudando todos esses conceitos e começando a aplicar esses Padrões no software que desenvolvemos. Nosso objetivo é ter, cada vez mais, um serviço de qualidade, baseado em sistemas seguros e fáceis de dar manutenção. Com isso poderemos atender nossos clientes com rapidez sem assumir nenhum tipo de débito técnico que possa inviabilizar nosso crescimento.

Aguardamos muitas sugestões e dúvidas sobre o assunto. Estamos mutio interessados em falar e aprender mais sobre DDD.

Enviar por E-Mail

Este post foi feito em 2 de março de 2009 às 12:46 por Daniel Cukier na(s) categoria(s) DDD. Você pode seguir estas respostas pelo feed RSS 2.0. Você pode deixar um comentário ou fazer um trackback do seu próprio site.