Tag: Domain-Driven Design

Categories
Engenharia de software Eventos

[QCon 2007] Eric Evans: Strategic Design

O Eric Evans, autor do livro Domain-Driven Design, fez mais uma excelente apresentação entitulada “Strategic Design“. Dessa vez a apresentação foi sobre como implementar técnicas de Domain-Driven Design em projetos de software.

Qcon 2007 - Eric EvansSegundo o Eric, por conta do tamanho das equipes de software é impossível ter somente programadores excelentes. Isso faz com que nem todas as partes do um sistema sejam bem desenhadas, isso é fato. No entanto você pode fazer com que algumas partes do sistema sejam bem desenhadas e é essecial que isso seja feito no domínio da aplicação, que é o local onde está a complexidade crítica da maioria dos sistemas.

Uma coisa importante que ele frisou é que não pode existir um domínio corporativo usado por todas as aplicações (tipo “one ring to rule them all”), porque é impossível criar um domínio que atenda a todos os softwares. Cada aplicação deve ter o seu próprio domínio que deverá ser cuidadosamente projetado, dento de um contexto, para resolver os problemas que a alicação se propõe.

Algumas estratégias para implementar um bom domínio são:

  • Desenhe um mapa do contexto e sempre siga-o. Isso vai te ajudar a saber quais conceitos devem ser mapeados no seu domínio ou não e te impedir de perder o foco do sistema.
  • Trabalhe com os líderes do negócio para definir o domínio do sistema. E continue sempre trabalhando em conjunto com eles enquanto o domínio se especializa e evolui.
  • Crie uma plataforma que suporte trabalhar e evoluir o domínio. E mantenha esta plataforma protegendo o domínio.
  • Trabalhe com a gerência para ter liberdade de criação no contexto do domínio.
  • Desenvolva e modele o domínio. O domínio sempre evoluirá e será destilado ao longo da vida do software.

E como em toda a apresentação do Eric têm que acontecer alguma coisa estranha, tivemos um falso alarme de incêncio bem no meio da apresentação! O pessoal tomou um baita susto porque começou a tocar o alarme muito alto e a piscar um monte de luzes e todos tiveram que sair do hotel. No fim das contas era um alarme falso. Nunca mais jogo fumaça naqueles detectores!!! (hahahaha, isso obviamente é sacanagem, eu jamais faria isso… – eu teria acendido um isqueiro no detector de fogo e todos ficariam molhados, que é bem mais legal!)

Download

Categories
Engenharia de software Eventos

[QCon 2007] Martin Fowler e Neal Ford: Domain Specific Languages

Segundo dia de QCon e hoje foi a vez de Martin Fowler e Neal Ford falarem sobre Domain Specific Languages.

QCon 2007 - Martin Fowler - Domain Specific LanguagesCom dois profissionais desse nível dá pra imaginar como o tutorial foi espetacular! O Fowler é sem sombra de dúvidas o melhor palestrante que já tive a oportunidade de ver. O ritmo que ele impõe é sensacional e a paixão com que ele fala do assunto é contagiante!

Para melhorar ainda mais o dia começou com uma ótima notícia: o Fowler está escrevendo neste momento um novo livro sobre DSLs. O livro já está no forno há um ano e já tem muita coisa escrita. Toda a apresentação de hoje foi baseada no seu novo livro e inclusive tivemos acesso a todo o material da sua pesquisa e o primeiro draft do livro! Está sensacional! O Neal também está escrevendo um livro sobre Ruby e DSLs, porém pelo que eu entendí está num estágio bem menos avançado.

Como o material da apresentação fará parte desse novo livro a distribuição foi proibida. Já que não dá para colocar o material aqui vou falar resumidamente sobre os assuntos abordados durante o dia, que foi dividido em três grandes partes.

Na primeira parte os dois apresentaram um introdução sobre o que são DSLs e como elas podem ser úteis. Eles criaram um framework imaginário (uma máquina de estados) e começaram a mostrar todos os problemas de quando este framework é desenvolvido como uma API. Em seguida eles criaram uma “casca” em torno dessa API (uma Fluent Interface) para facilitar o uso da mesma.

A partir daí eles definiram os conceitos de DSL interna e externa. DSLs internas são como as Fluent Interfaces, que são escritas na linguagem do sistema (Java, por exemplo). DSLs externas são escritas em qualquer outra linguagem separada da linguagem do sistema e precisam de um compilador ou interpretador para serem executadas.

Os benefícios mais notáveis de construir DSLs são a melhoria na produtividade do desenvolvimento (porque o código da lógica de negócio é mais limpo e mais fácil de ser evoluído) e a melhoria na comunicação com os especialistas do domínio (porque as regras de negócio são escritas numa linguagem conhecida pelo especialista, facilitando o entendimento do código).

QCon 2007 - Neal Ford - Domain Specific LanguagesNo entanto também existem uma série de problemas. É necessário ter muito cuidado para criar um design bom que possa ser evoluído ao longo do tempo. DSLs algumas vezes são extremamente complicadas de serem implementadas mas o impacto é muito positivo. Um exemplo real pode ser visto em um post que fiz há algumas semanas sobre uma Fluent Interface que implementei em um projeto, que trouxe vários benefícios interessantes.

Uma das formas mais comuns de se criar DSLs é o padrão que eles chamaram de “Framework Out-Language In”, onde você começa com a construção de um framework e em seguida define uma DSL em volta dele (como um Façade). Utilizar técnicas de Domain-Driven Design pode ajudar bastante pois evoluindo a Ubiquitous Language você enriquece a comunicação/vocabulário do sistema, que fatalmente irá colaborar para a criação de DSLs mais ricas e que refletem melhor ainda o domínio.

Não é nem preciso dizer que eles bateram muito forte na questão dos testes. Como a programação de DSLs é complexa, é essencial testar muito bem cada pequena parte e variação possível! Além disso técnicas de Test-Driven Development certamente ajudarão a criar DSLs mais fáceis de serem usadas (porque se não for fácil de usar você fez alguma coisa errada).

Na segunda parte da apresentação o Neal Ford apresentou um tutorial prático de como criar DSLs internas em Java, Groovy e Ruby.

Essa apresentação foi bem mão-na-massa e ensinou várias técnicas para criação de DSLs internas. Ele mostrou vários exemplos utilizando encadeamento e aninhamento de métodos fazendo wrappers em coisas conhecidas como Log4J e java.util.Calendar.

Na terceira e última parte o Fowler apresentou um tutorial sobre como projetar e quais ferramentas podem ser utilizadas para a criação de DSLs externas. Essa apresentação foi bem mais teórica que a do Neal.

Ele mostrou como fazer para criar um parser de sintaxe, que consiste em um “lexer” (um tokenizador de texto), um parser (analisador sintático que organiza os tokens em uma árvore), um analisador semântico (que checa as regras de construção das frases) e a produção de alguma saída (que significa produzir qualquer coisa útil, como popular certos objetos e fazer certas operações).

Qcon 2007 - DSLDomain Specific Languages é uma técnica muito antiga. Muito antes do próprio Fowler começar a escrever e estudar sobre o assunto várias DSLs já existiam por aí (o melhor e mais clássico exemplo é a linguagem SQL utilizada em bancos de dados).

A opinião dos dois é que DSLs realmente prometem trazer várias melhorias no desenvolvimento de software, especiamente no que diz respeito a programação das regras de negócio e interação com os especialistas de domínio. No entanto eles acham que não existirá um dia em que os programadores serão desnecessários e que tudo será feito a base de DSLs, tampouco que este seja um assunto que terá um boom enorme e que mudará a vida de todo mundo. Eles acham que trata-se simplesmente de mais uma técnica útil para desenvolver software de qualidade.

Categories
Domain-Driven Design Engenharia de software Eventos

[QCon 2007] Eric Evans: Domanin-Driven Design

Qcon 2007 - Eric Evans - Domain-Driven DesignA apresentação do Eric Evans hoje sobre Domain-Driven Design foi excelente! A abertura do evento não poderia ter sido melhor!

Grande parte do que ele apresentou faz parte do seu livro sobre DDD, incluindo alguns dos exemplos usados no tutorial. Mas isso não fez com que as coisas ficassem menos interessantes. Muito pelo contrário, as discussões foram excelentes.

Falamos inicialmente sobre as características de um bom design de domínio. Na opinião do Eric um bom design é aquele que você consegue explicar para uma pessoa qualquer e ela entende mesmo não sendo especialista no negócio/domínio. Sobre codificação, o Eric falou que se interessa bastante pela clareza trazida por Fluent Interfaces, e DSLs internas e tenta usá-las sempre que possível pois aumenta muito a legibilidade do código. Além disso ele acredita que o uso de Behaviour-Driven Development é interessante no processo exploratório de um domínio e pode te ajudar a identificar e corrigir problemas de design.

Uma das frases que o Eric falou me lembrou a discussão que rolou na semana passada no GUJ sobre testes, TDD e etc: “Estamos no ano do Test-Driven Development e criar designs testáveis é essencial!”. Não quero acender novamente a discussão mas não posso deixar de dar a minha opinião nessa história. Realmente é inaceitável um software nos dias de hoje não ter uma suite de testes decente, não só pelos testes em sí mas por toda a influência positiva que isso traz no design do código, pela segurança que te dá para incluir novas funcionalidades e modificar existentes, segurança para corrigir bugs e tudo mais. Para mim é simplesmente impossível programar sem testes!

Guilherme Chapiewski e Eric EvansInfelizmente não consegui todo o material do curso porque o Eric utiliza esses materiais nos seus treinamentos e por isso não os disponibiliza publicamente. Mas eu consegui o Domain-Driven Design Pattern Summaries, que é um resumo de 39 páginas do livro dele com algumas coisas a mais. Achei bem interessante para se usar como referência. Esse resumo contém informações bem objetivas sobre todos os padrões apresentados no livro de DDD.

Além desse material o InfoQ disponibilizou a palestra Putting The Model To Work que foi uma das que o Eric apresentou para nós. Essa não foi exatamente a apresentação que tivemos mas foi bem parecida.

Para os leitores assíduos de blog, aí vai uma boa notícia: num dos intervalos eu perguntei para o Eric porque que ele não tinha um blog. Ele disse que ultimamente muitas pessoas têm feito essa pergunta e disse que está preparando alguma coisa nesse sentido. Perguntei sobre quando ele planeja lançar isso e ele disse que seria em breve! Com certeza será mais uma ótima fonte para leituras.

E para terminar, a gafe do dia: na hora do intervalo subitamente começamos a ouvir na sala vários barulhos estranhos de mictório e pia de banheiro… O Eric deu bobeira e foi no banheiro com o microfone sem fio ligado! Ao menos constatamos que o microfone era de boa qualidade porque o banheiro era meio longe, haha!

Categories
Engenharia de software

QCon 2007, aí vou eu!

Estou arrumando minhas malas e partindo daqui a pouco para a QCon 2007!

No último mês eu tenho me preparado bastante pra esse evento e justamente por isso que não tenho postado com tanta frequência. Não é todo dia que se pode ter aulas de Domain-Drinven Design com o próprio Eric Evans, de XP com o próprio Kent Beck ou de Domain Specific Languages com Martin Fowler e Neal Ford, por isso aproveitei esses dias pra refrescar algumas coisas na cabeça para poder aproveitar tudo o máximo possível!

Nos dois primeiros dias eu pretendo justamente assistir os cursos de DDD do Evans e de DSLs do Fowler. Esses tutoriais duram um dia inteiro e são hands-on, aplicados num laboratório. Acho que vai ser muito legal!

Além deles vários outros apresentadores como Ted Neward, Cedric Beust, Jeff Sutherland, Obie Fernandez, Jay Fields e Rod Johnson farão uma semana inteira de apresentações sobre desenvolvimento ágil, arquitetura de software e tudo mais que alguém poderia querer para ter uma semana mais que divertida.

Vou tentar conseguir o máximo de material possível nas apresentações que eu for e ao longo da semana vou postando por aqui!

Categories
Domain-Driven Design Refactoring

Tiny Types

Continuando na “luta” para criar sistemas mais fáceis de se entender, me lembrei de dar uma olhada nos Tiny Types apresentados pelo Darren Hobbs.

O CV tinha passado esse link há algum tempo e eu havia olhado superficialmente. Até que nessa história de fazer Fluent Interfaces e Domain-Driven Design acabei me lembrando que isso poderia ser útil.

Os Tiny Types enriquecem o domain model e trazem alguns outros benefícios legais citados pelo Darren em seu texto. Para as próximas features vou experimentar essa estratégia para ver no que vai dar…

Categories
Domain-Driven Design Refactoring

Refatorando para Fluent Interface

Ultimamente tenho passado boa parte do meu tempo trabalhando numa aplicação chamada WebMediaAPI. Trata-se de uma… ahm… API de uso interno que tem como objetivo padronizar, centralizar e facilitar o acesso à mídias e seu consumo em sites da Globo.com.

Por exemplo, quando o pessoal do G1 quiser colocar vídeos no seu site, ao invés de dar vários SELECTs em tabelas que eles não entendem e não conhecem, a idéia é que eles possam usar um JAR na aplicação deles que encapsula várias funcionalidades oferecidas pela nossa infraestrutura de WebMedia, simplificando o trabalho deles (pois não terão que descobrir como inventar a roda) e o nosso (centralizando e organizando o consumo de mídias na empresa).

No início do projeto um dos maiores desafios foi estabelecer como seria a fachada desta API. Nós tentamos alguns formatos e como precisávamos lançar logo a primeira versão acabamos optando por uma interface “tradicional” e simplificada. Para ter uma idéia melhor, veja o código para selecionar os últimos vídeos publicados do programa “Altas Horas”:

int quantidade = 5;
long programaId = 456;
Set midias = new HashSet();
 
WebMediaServices webMediaServices = WebMediaFactory.getServices();
List idsMidias = webMediaServices
	.getIdsUltimasMidiasPublicadasPorPrograma(quantidade, programaId);
 
for (Iterator iter = idsMidias.iterator(); iter.hasNext();) {
   Long midiaId = (Long) iter.next();
   Midia midia = webMediaServices.getMidia(midiaId.longValue());
   midias.add(midia);
}

Não é muito difícil entender o funcionamento deste código… Só que ele poderia ser muito melhor!

Esta interface pode até funcionar mas não é nem um pouco intuitiva. A classe WebMediaServices como pode-se imaginar ficou com dezenas de métodos e virou basicamente um grande saco de funcionalidades. Qualquer método simplesmente ficava nesta classe – o que não é nem um pouco elegante.

Depois de algum tempo tive a idéia de refatorar a API para uma Fluent Interface. A idéia é tentar fazer algo que se assemelha a uma DSL interna, que não é nada mais do que uma API com nomes interessantes. Ao invés de um saco de métodos a WebMediaAPI agora é acessada através de uma interface semânticamente organizada e seu design é pensado para ser legível e… fluente!

Veja como ficou o novo código para selecionar os últimos vídeos publicados do programa “Altas Horas” (exatamente a mesma coisa que o código anterior faz):

Long altasHoras = new Long(456);
Set videos = WebMediaAPI.videos().recentes().doPrograma(altasHoras);

Bem mais elegante!

O lado negativo é que quanto mais fácil a API torna-se para o cliente mais difícil torna-se sua implementação. Construir uma fluent interface muitas vezes me fez perder algumas horas pensando como certas coisas seriam feitas, mas eu gostei do resultado final e acho que para esse tipo de aplicação valeu a pena.

Para mostrar a diversidade e simplicidade da nova API, veja mais alguns exemplos (repare que eu não tenho que dizer nada sobre o que eles fazem para você entendê-los):

// exemplo 1
Set programas = WebMediaAPI.programas().comTitulo("Fantastico");
 
// exemplo 2
Long multishow = new Long(123);
Set videos = WebMediaAPI.videos().favoritos().doCanal(multishow);
 
// exemplo 3
Long destaquePrincipalGloboVideos = new Long(123);
Integer quantidadeMaxima = new Integer(10);
Set videos = WebMediaAPI.videos().relacionados().aoCanal()
	.doVideo(destaquePrincipalGloboVideos, quantidadeMaxima);

Ainda temos um longo caminho pela frente e muita coisa ainda será melhorada, mas já dá para perceber uma difirença significativa entre as duas versões.

Categories
Domain-Driven Design

Em qual língua você programa?

Muitas vezes fico em dúvida sobre qual língua usar nos meus sistemas. Sempre me sentí muito mais confortável programando em inglês do que em português mas nunca achei isso muito certo já que nossa língua nativa é o português. Já houveram casos de eu trabalhar com alguém que só sabia português e apesar de achar que nessa profissão quem não sabe inglês não vai à lugar nenhum não podia simplesmente inviabilizar o trabalho da equipe.

No último projeto que participei nossa equipe usou somente português. Algumas coisas boas aconteceram como o fato de termos incorporado a linguagem do negócio ao sistema. Isso é muito bom porque a grande maioria das entidades do sistema são coisas do mundo real e as discussões são sempre sobre coisas reais e não sobre metáforas (frequentemente mal feitas).

Porém também houveram pontos negativos. Por exemplo, uma determinada classe de serviços, que em inglês seria algo como MediaServices, teve que ser chamada de ServicosDeMidia. No fim das contas acabei optando por tirar a preposição (acho que o “de” é uma preposição, certo?) ficando somente ServicosMidias. Resolví retirá-la porque inúmeras classes ficaram com “De” no nome e ficou meio esquisito. O ruim é que não é exatamente assim que a gente fala naturalmente e fica um pouco estranho…

No fim das contas acho que o ideal é utilizar a língua do negócio, seja ela português ou inglês. Desta forma quando você for conversar com os clientes (product owners) você não terá o overhead de mapear todos os conceitos reais para a linguagem ou metáforas usadas no sistema. Com isso a conversa entre os clientes e os desenvolvedores fica muito mais produtiva já que todos estão falando sobre as mesmas coisas.