Standup Meeting

O sol estava brilhando e bateu forte na nossa janela. Como o pessoal tinha ido dormir um pouco mais tarde, também acabamos acordando um pouco mais tarde. Como de costume, fizemos nosso standup meeting as 11h. A moça que contratamos para limpar a casa e cozinhar não veio nesse dia. Acabamos tendo que dar um jeito com as tarefas da casa.

Durante quase o dia todo, uma das duplas ficou investigando o bug do dia anterior, tentando reproduzir o comportamento em ambiente de teste. Não conseguiram evoluir muito, o que nos deixou bastante frustrados.

Eu fiquei trabalhando com um outro desenvolvedor numa mudança importante e grande que tínhamos que fazer no site, que envolvia a arquitetura e o design das páginas. Passamos praticamente o dia todo em cima do código, testando a nova arquitetura, fazendo um protótipo. Não conseguimos terminar todos os testes, mas evoluímos bastante.

Programando da beira da piscina

Na hora do almoço, fomos para a piscina e churrasqueira. O sol estava bombando. Aproveitei para fazer uns exercícios do Kung Fu. Quase todos também foram na sauna (só funcionou a seca). Um outro pessoal aproveitou a piscina para nadar. Também levamos os computadores e ficamos trabalhando da beira da água. Um momento mágico!

Os que ficaram responsáveis pela churrasqueira salgaram a carne demais, não acenderam o fogo direito. Além de tudo, a picanha tava dura igual uma pedra! Também colocamos umas batatas, cebolas e alho embrulhados no alumínio, mas não fizeram muito sucesso. No fim, a única coisa que se salvou do churrasco foi a berinjela. Acabamos com o arroz, feijão e salada do dia anterior e esse foi nosso almoço.

De noite, um de nós lembrou que o dia era de lua cheia e propôs uma meditação em grupo. Dizem que nesse dia, a energia da lua faz com que a meditação seja mais poderosa. Alguns gostaram da ideia e fizeram essa meditação que durou cerca de uma hora.

Enquanto isso, do que sobrou da carne dura do almoço, um pessoal tentou moer no liquidificador e fazer uns croquetes. Disseram que o gosto até que estava bom, mas continuava dura. A solução foi fritar uns hambúrgueres e comer lanche. Fizemos um vídeo da movimentação da cozinha de noite.

Meu quarto - espaço privado

Depois da janta, continuei trabalhando na história de arquitetura e fomos até meia noite nela. Nesse dia eu tive um insight muito interessante. Depois da piscina, resolvi dar uma passada no meu quarto para trocar de roupa. Quando eu estava sozinho no quarto, senti uma paz e um alívio muito grande de estar lá sozinho. Percebi a importância que era ter um espaço privado na casa. Notei que a distribuição de cômodos do lugar ajudava muito. Havia na casa uma parte de convívio compartilhada, mas também uma boa área íntima, permitindo que as pessoas se retirarem quando achassem conveniente.

Lembrei de ter lido algo a respeito de espaços público/privados no livro Peopleware, do Tom De Marco. Ele cita alguns padrões de arquitetura catalogados pelo Christopher Alexander. Tom De Marco enfatiza a importância de se ter num ambiente de trabalho, num escritório, espaços públicos e individuais harmoniosamente distribuídos e equilibrados. Pouca gente sabe, mas os padrões do Alexander influenciaram toda indústria de software: padrões de projeto (os famosos Design Patterns), Domain Driven Design, o livro de  Refatorações, Métodos ágeis são alguns dos muitos exemplos de conceitos da área de software que surgiram na comunidade de software que estuda padrões.

Pontos Positivos do Dia:

• A piscina estava muito boa
• Sol durante quase todo o dia
• Meditação da Lua cheia
• Stop Motion na cozinha na hora da preparação do jantar
  
• Consegui trabalhar e avançar a arquitetura de uma história importante junto com outro desenvolvedor

Pontos Negativos do Dia:

• As duas saunas não funcionam juntas
• A carne do churrasco foi um fiasco
• Uma dupla perdeu quase o dia todo investigando o bug do dia anterior e não encontraram a causa do bug

Em agosto de 1993, Kent Beck e Grady Booch patrocinaram um retiro na montanha, onde um grupo de pessoas chegou a um consenso sobre os fundamentos em padrões de software. Ward Cunningham, Ralph Johnson, Ken Auer, Hal Hildebrand, Grady Booch, Kent Beck e Jim Coplien se basearam fortemente nas ideias de Alexander e suas próprias experiências, formando um casamento entre objetos e padrões. O grupo concordou que estávamos prontos para construir, sobre as fundações do trabalho de Erich Gamma sobre padrões orientados a objetos, e usar esses padrões da mesma forma que Christopher Alexander usa seus padrões para planejamento urbano e construções arquitetônicas. O encontro do grupo se deu ao lado (side) de um monte (hill), daí o nome Hillside.

Desde então, o Hillside Group se tornou uma organização educacional sem fins lucrativos, que patrocinou e ajudou a organizar várias conferências (Plop Conference, EuroPlop, ChiliPlop, KoalaPlop, Mensore PLoP, SugarloafPLoP, e UP97), além de ter sido responsável pela edição e publicação da série de livros “Pattern Languages Of Program Design”.

A conferência

Os eventos do PLoP são encontros bastante diferentes das conferências tradicionais que estamos acostumados. Normalmente, quando vamos a uma conferência, ficamos quase o dia todo assistindo palestras, normalmente ministradas por pessoas com bastante experiência. Nesses eventos, temos poucas oportunidades de conhecer e conversar com os outros. Isso até acontece, mas quase sempre de forma rápida e superficial.

Já no PLoP, a interação entre os participantes é bastante intensa e rica. Normalmente o evento dura 3 dias, durante os quais você realmente conhece as pessoas que estão lá. As refeições e o hotel já fazem parte do pacote do preço da conferência, então você acaba tomando café, almoçando e jantando com esse grupo. Como consequência disso, temos a oportunidade de manter conversas longas e produtivas com os participantes.

Além das refeições fartas e deliciosas, o PLoP também inclui várias dinâmicas e jogos em grupos (games), cujo objetivo é aproximar os participantes, motivando e estreitando as relações pessoas entre todos. Os jogos são sempre divertidos, engraçados, tornando o ambiente mais seguro, informal e, principalmente criativo. Pode parecer um detalhe, mas esses jogos são fundamentais para o sucesso e

qualidade do evento.

Design Patterns (Padrões de projeto) – meio óbvio né… Os assuntos que discutimos são quase sempre relacionados com desenvolvimento de software, com foco principal em padrões. Poucos desenvolvedores se dão conta, mas boa parte do que conhecemos sobre técnicas e boas práticas em desenvolvimento de software vieram de alguma maneira da comunidade de padrões. Apenas para citar alguns exemplos:

• Testes com dublês (stubs, mocks, etc)
• Scrum nasceu de padrões
• Métodos ágeis nasceram na comunidade de padrões
• Padrões de arquitetura
• TDD (Test Triven Development)
• Refatoração de código
• Domain Driven Design (DDD)
• Model Driven Design (MDD)

Submissão dos artigos

Para participar do PLoP, é preciso submeter para a conferência, alguns meses antes, uma proposta de artigo. Se o seu artigo estiver num nível que considerado adequado pelos avaliadores, você é aceito para o chamado processo de shepherding. O termo shepherd em inglês significa pastor – a ideia é que você será conduzido por um “mestre” no processo de escrita do seu artigo. Para cada autor, são escolhidos 1 ou 2 shepherds, que lerão o artigo atentamente e farão várias sugestões de melhoria.

Esse processo dura em torno de dois ou três meses. Durante esse tempo, você troca várias mensagens com os shepherds, mandando novas versões melhoradas do artigo. No meu caso, foram 4 iterações. O artigo que eu escrevi era sobre quatro novos padrões para introduzir novas ideias. Minha ideia era adicionar novos padrões ao catálogo original da Linda Rising e Mary Lynn Manns (livro Fearless Change). O artigo era uma evolução da minha tese de mestrado.

Ninguém melhor do que as próprias Linda e Mary Lynn para me ajudarem a escrever esses padrões, por isso elas foram escolhidas como minhas shepherds. A ajuda que obtive delas foi incrível, o que me possibilitou ter um artigo num nível adequado para ser aceito para a conferência. Após o processo de shepherding, você precisa enviar o artigo novamente para avaliação. Novamente, os avaliadores lêem o artigo e decidem se ele é adequado para ser trabalhado na conferência, num processo que eles chamam de Writers Workshop.

Writers Workshop

O “carro chefe” das conferências PLoP são o que chamamos de Writers Workshop (Oficina dos Escritores). O conceito surgiu em comunidades de poetas, que se encontravam frequentemente para debater e aprimorar suas poesias. A dinâmica do Writers Workshop consiste na troca de experiência entre vários autores. Quem trouxe essa ideia para o mundo da computação foi o cientista Richard P. Gabriel. Ele escreveu um livro sobre o assunto, descrevendo detalhadamente como conduzir a oficina.

Funciona basicamente assim: vários autores de artigos formam um grupo (normalmente de umas 10 pessoas). Durante os três dias do PLoP, esse grupo se encontra várias vezes. Em cada encontro eles escolhem um dos artigos para aprimorar. O autor do artigo deve obrigatoriamente estar presente, mas seu papel é apenas de ouvinte. Os outros fazem comentários, dando sugestões positivas e práticas de como melhorar o artigo. O autor anota essas considerações, para posteriormente aplicá-las a uma nova versão do artigo.

Uma regra importante na oficina é a de que o artigo tem que falar por si só, ou seja, o autor não pode ficar dando explicações para os outros de coisas que deveriam estar claras no artigo. Se posteriormente alguém for ler o seu artigo, você não estará presente para dar suas explicações. Por isso, é importante que todas as ideias que você quer transmitir estejam claras no artigo.

No final, o resultado extremamente satisfatório. O objetivo da comunidade de padrões é criar uma vasta literatura sobre soluções de problemas, que se mostraram eficazes em alguns contextos e que podem servir de guia para que outros apliquem as mesmas soluções e obtenham sucesso em seus projetos. Normalmente um padrão não é algo cabulosamente complicado, mas sim coisas simples, porém muito poderosas se aplicadas corretamente. Um fator importante que torna um padrão poderoso é a forma como ele é documentado. Autores de padrões devem tomar o cuidado de documentar muito bem um novo padrão, de maneira que ele seja amplamente compreendido. O Writers Workshop é fundamental para que texto final de um padrão seja lapidado ao extremo, tornando conciso, objetivo, prático e eficaz.

Minha participação

Nesse ano, eu participei do PLoP como autor de um artigo junto com o Professor Fabio Kon. O líder do meu grupo no Writers Workshop foi o próprio Richard Gabriel, ou seja, o cara que inventou a oficina! Foi uma surpresa maravilhosa tê-lo como um dos conselheiros para o meu artigo. Além do Richard, outros 6 autores faziam parte do grupo e ouvi comentários extremamente positivos e importantes para melhorar o artigo.

Para aqueles que tiverem interesse, podem ler a versão preliminar do artigo aqui. Durante os próximos meses, trabalharei para incorporar as sugestões obtidas na oficina de escritores. Essa nova versão será enviada para os organizadores da conferência, que farão uma avaliação final e, caso o artigo esteja satisfatório, será publicado na biblioteca digital da ACM.

Veja outras fotos do PLoP 2011

]]> http://www.agileandart.com/2011/10/24/plop-a-conferencia-de-padroes/feed/ 3 http://www.agileandart.com/2011/10/19/splash-antiga-oopsla/?utm_source=rss&utm_medium=rss&utm_campaign=splash-antiga-oopsla http://www.agileandart.com/2011/10/19/splash-antiga-oopsla/#comments Wed, 19 Oct 2011 21:52:19 +0000 Daniel Cukier http://www.agileandart.com/?p=588 OOPSLA

Em 1985, um grupo de 4 pioneiros em programação orientada a objetos decidiu organizar nos EUA uma conferência sobre programação de sistemas orientados a objetos. No grupo estavam Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock, e a conferência foi chamada de OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications). A primeira OOPSLA aconteceu no Hotel Marriott, em Portland, Oregon, em novembro de 1986. Cerca de 600 pessoas participaram, 50 artigos foram apresentados e os participantes ouviram sobre Smalltalk, Lisp, Flavors, CommonLoops, Emerald, Trellis/Owl, Mach, Prolog, ABCL/1, prototypes, e programação concorrente e distribuída de pessoas como Danny Bobrow, Gregor Kiczales, Rick Rashid, Andrew Black, Dave Ungar, Henry Lieberman, Ralph Johnson, Dan Ingalls, Ward Cunningham, Kent Beck, Ivar Jacobson e Bertrand Meyer.

Essa gama enorme de tópicos e pesquisadores definiu o tom da conferência, que se tornou forum para alguns dos principais desenvolvimentos de software das últimas duas décadas. Foi na OOPSLA que nasceram coisas como cartões CRC, CLOS, Padrões de Projeto (Design Patterns, Self, métodos ágeis, arquiteturas orientadas a serviço (SOA), wikis, UML, TDD, refatoração, Java, compilação dinâmica, programação orientada a aspectos, só para citar algumas delas. Nem sempre falando sobre objetos, mas nunca deixando o assunto de lado, a conferência cresceu de 600 para 2500 participantes no seu pico, sendo ainda forte com cerca de 1300 pessoas mesmo depois do surgimento de uma série de conferências sobre padrões, Eclipse, EclipseCon, Agile e AOSD.

No final dos anos 90 – com o sucesso de Smalltalk e Java nos negócios e C++ na engenharia – OO se tornou amplamente adotada e a OOPSLA mudou de uma conferência que trabalhava para tornar OO prático e compreensível para trabalhar nos problemas do mundo sempre mutante da computação, tanto na inventando novas técnicas e tecnologias quanto melhorando e expandindo teorias. O que permaneceu foi a paixão por inovação e o hábito de criar comunidades.

Onward!

No começo dos anos 2000, algumas pessoas da OOPSLA sentiram que a conferência se beneficiaria muito se fosse criada uma nova trilha de publicação de artigos focados em ideias inovadoras além de OO, e em formatos de artigos que normalmente não seriam aceitos na OOPSLA. Nasce então a Onward!, coordenada por Richard Gabriel. Onward! foi a primeira conferência patrocinada pela ACM a dar voz a “artigos ideias” no âmbito da aceitação acadêmica. Muitas outras conferências seguiram esse modelo depois.

SPLASH

Na metade dos anos 2000, ficou claro que a estrutura de organização da OOPSLA e Onward jutas precisavam ser refatoradas, não apenas para que ambas existissem ao mesmo tempo, mas também para fornecer a possibilidade de incluir novas trilhas de artigos, mantendo a conferência nova e moderna. Depois de vários debates entre as comunidades, ficou finalmente decidido criar um guarda-chuvas de conferências: assim nasceu a SPLASH, a conferência da ACM em Sistemas, Programação, Linguages e Aplicações: Software para a Humanidade.

Desde 2010, a SPLASH tem mantido e administrado a OOPSLA, Onward! e uma variedade de outros eventos, como o Simpósio de Educadores, Workshop de Experiências, Painéis, etc. OOPSLA é hoje “apenas” a trilha técnica de artigos de pesquisa de alta-qualidade, que foi desde o início o coração desse conferência. Ao mesmo tempo, a OOSPLA aumentou o escopo de tópicos muito além de OO, aceitando hoje uma enorme variedade de artigos relacionados a programação. Ao criar a SPLASH como um guarda-chuvas de conferências, a comunidade pode agora sustentar novas trilhas de artigos que eventualmente não cabem na OOPSLA, mas que ainda sim são relacionados. Assim, permite-se o espaço para inovação, assim como aconteceu com a Onward!

E eu com isso?

Esse ano (2011), eu terei o privilégio de participar da SPLASH pela primeira vez (algo que eu já gostaria de ter feito há bastante tempo

A SPLASH tem um programa de Estudantes Voluntários, onde nós, estudantes, podemos participar da conferência de graça em troca de algumas horas de trabalho para ajudar na organização. Eu me inscrevi nesse programa de estudantes voluntários e fui aceito.

Além disso, eu tive dois artigos aceitos: um na Onward! e outro na PLoP (outra conferência que faz parte do guarda-chuvas da SPLASH). Para esses dois artigos, participarei do que eles chamam de Writers Workshop (Workshop de Escritores). O objetivo é trabalhar durante várias horas junto com os maiores (acreditem, são os maiores mesmo!) especialistas da área e anotar sugestões de melhorias para os artigos, que posteriormente farão parte das publicações científicas da conferência. Acima de tudo, é uma oportunidade maravilhosa de aprender muito e conhecer muita gente legal.

Depois que os artigos ficarem prontos (e bem melhorados após os comentários das pessoas na conferência) eu publico aqui nesse Blog.

Próximos passos

Ao longo da próxima semana, farei (na medida do possível alguns posts aqui nesse blog contando um pouco mais sobre essa conferência incrível. Farei, como de costume, várias fotos e, talvez, alguns vídeos. Dessa forma, consigo compartilhar um pouquinho dessa experiência quem não pôde ir desta vez!

It was a great event! For more information about miniPLoP, check the event website: http://www.miniplop.ita.br/Apresentacao.html

Um padrão é uma regra de três partes que expressa a relação entre um 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 a essência da Orientação a Objetos também tem coisas como:

• Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do domínio é algo essencial quando se faz DDD (o pessoal de métodos ágeis já sabe disso faz tempo);
• Favorecer reutilização: os blocos de construção, que veremos adiante, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares;
• Mínimo de acoplamento: Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos;
• Independência da Tecnologia: DDD não foca em tecnologia, mas sim em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia usada não seja importante, mas essa não é uma preocupação de DDD.

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, que apresentaremos a seguir.

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 (devman: Linguagem comum, com termos bem definidos, que fazem parte do domínio do negócio e que são usados por todas as pessoas que fazem parte do processo de desenvolvimento de software). 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 ter 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 com o nome de data limite.

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

Utilizando a Linguagem Ubíqua criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A idéia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo. Só aparece no modelo aquilo que está no negócio.

Em um time que cria software temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Num processo ágil defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo, com todas as pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modelers). Se os programadores não se sentirem responsáveis pelo modelo ou não entenderem como o modelo funciona, então o modelo não terá relação alguma com o software produzido por essas pessoas.

O processo de maturação de um sistema desenvolvido usando MDD deve ser contínuo. O modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

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

Uma vez que decidimos criar um modelo usando MDD, precisamos, inicialmente, isolar o modelo de domínio das demais partes que compõem o sistema. Essa separação pode ser feita utilizando-se uma arquitetura em camadas (Figura 1), que dividirá nossa aplicação em quatro partes:

• Interface de Usuário – parte responsável pela exibição de informações do sistema ao usuário e também por interpretar comandos do usuário;
• Aplicação – essa camada não possui lógica de negócio. Ela é apenas uma camada fina, responsável por conectar a Interface de Usuário às camadas inferiores;
• Domínio – representa os conceitos, regras e lógicas de negócio. Todo o foco de DDD está nessa camada. Nosso trabalho, daqui para frente, será aperfeiçoar e compreender profundamente essa parte;
• Infra-estrutura – fornece recursos técnicos que darão suporte às camadas superiores. São normalmente as partes de um sistema responsáveis por persistência de dados, conexões com bancos de dados, envio de mensagens por redes, gravação e leitura de discos, etc.

Figura 1. Arquitetura em camadas, utilizada para separar o domínio do resto da aplicação.

Depois de dividirmos o sistema em camadas, nos preocuparemos apenas com a camada de domínio. Para modelar essa parte, utilizamos alguns Padrões propostos em DDD. Esses padrões são chamados de blocos de construção e serão utilizados para representar nosso modelo abstrato. Esses blocos podem ser:

• Entidades – classes de objetos que necessitam de uma identidade. Normalmente são elementos do domínio que possuem ciclo de vida dentro de nossa aplicação: um Cliente, por exemplo, se cadastra no sistema, faz compras, se torna inativo, é excluído, etc.;
• Objetos de Valores – objetos que só carregam valores, mas que não possuem distinção de identidade. Bons exemplos de objetos de valores seriam: strings, números ou cores. Por exemplo: se o lápis de cor da criança acabar e você der um novo lápis a ela, da mesma cor, só que de outra caixa, ela não vai se importar. Para a criança, o lápis vermelho de uma caixa é igual ao lápis vermelho de outra caixa. As instâncias de Objetos de Valores são imutáveis, isto é, uma vez criados, seus atributos internos não poderão mais ser modificados. Em Java, temos, por exemplo, a classe BigDecimal, muito utilizada para fazer cálculos com valores grandes. Na Listagem 1 observamos que, para multiplicar dois valores representados pela classe BigDecimal, não alteramos os objetos com os valores dos fatores da multiplicação. Para calcular 5 milhões vezes 30 milhões construímos cada um dos fatores e então obtemos o resultado, que será armazenado numa terceira variável. Após o cálculo, cada um dos fatores continuará armazenando o valor original. A saída do código será:


5000000
30000000
150000000000000


• Agregados – compostos de Entidades ou Objetos de Valores que são encapsulados numa única classe. O Agregado serve para manter a integridade do modelo. Elegemos uma classe para servir de raiz do Agregado. Quando algum cliente quiser manipular dados de uma das classes que compõem o Agregado, essa manipulação só poderá ser feita através da raiz;
• Fábricas – classes responsáveis pelo processo de criação dos Agregados ou dos Objetos de Valores. Algumas vezes, Agregados são relativamente complexos e não queremos manter a lógica de criação desses Agregados nas classes que o compõem. Extraímos então as regras de criação para uma classe externa: a fábrica;
• Serviços – classes que contém lógica de negócio, mas que não pertence a nenhuma Entidade ou Objetos de Valores. É importante ressaltar que Serviços não guardam estado, ou seja, toda chamada a um mesmo serviço, dada uma mesma pré-condição, deve retornar sempre o mesmo resultado;
• Repositórios – classes responsáveis por administrar o ciclo de vida dos outros objetos, normalmente Entidades, Objetos de Valor e Agregados. Os repositórios são classes que centralizam operações de criação, alteração e remoção de objetos. Em linguagens como Java e .NET, repositórios são comumente implementados usando-se frameworks como Hibernate ou Nhibernate. Já em RubyOnRails, o ActiveRecord faz o papel de repositório;
• Módulos – abstrações que têm por objetivos agrupar classes por um determinado conceito do domínio. A maioria das linguagens de programação oferecem suporte a módulos (pacotes em Java, namespaces em .NET ou módulos em Ruby). Um anti-padrão comum é a criação de módulos que agrupam as classes segundo conceitos de infra-estrutura. Um exemplo seria, ao se trabalhar com Struts, em Java, criar um pacote que conterá todas as Actions do sistema. Ao usar DDD devemos agrupar classes se esse agrupamento faz sentido do ponto de vista do domínio, ou seja, do negócio. Se tivermos, por exemplo, várias classes que compõem informações de Paciente num sistema médico, podemos criar um módulo chamado paciente e colocar classes como Ficha, PrescricaoMedica, RegistroDeConsulta e HistoricoDeCirurgias num mesmo pacote.

BigDecimal fiveM = BigDecimal.valueOf(5000000);
BigDecimal thirtyM = BigDecimal.valueOf(30000000);
BigDecimal result = fiveM.multiply(thirtyM);
System.out.println(fiveM);
System.out.println(thirtyM);
System.out.println(result);

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 e melhorado na medida em que se obtém maior compreensão de conceitos importantes do domínio. Muitas vezes alguns conceitos do domínio estão implícitos no código. O trabalho do desenvolvedor é tentar identificar esses 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 em métodos ou classes que dizem exatamente “o que” essas classes ou métodos fazem, mas não “como” elas fazem. Dizer “como” no nome do método quebra o encapsulamento, uma vez que quem chama o código saberá detalhes de implementação;
• Funções sem Efeitos-Colaterais – tentar deixar o código com o maior número possível de métodos que não alterem 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 que rodem automaticamente, ou colocar asserções no código que validem, após a chamada dos comandos, as alterações de estado esperadas.

Por exemplo, o dono de uma loja de tintas pode querer um programa que mostre para seus clientes o resultado da mistura de cores padrões. Inicialmente temos um código como no código abaixo. Não é possível, apenas olhando o nome do método (pinta), saber o que esse método faz. O que ele pinta? Um quadro? Um desenho? Uma parede? O que ele faz com a Tinta que ele recebe como parâmetro? Temos que olhar a implementação para saber o que está acontecendo de fato neste método.

public class Tinta{
	private int r;
	private int g;
	private int b;
 
	public void pinta(Tinta p){
		v = v + pinta.getV(); //volume é somado
		//várias linhas de código complexo
		//para misturar tintas
		//no final, r, g e b têm seus valores alterados
	}
}

Um possível teste para esse código seria assim:

public void testPinta(){
	//cria amarelo com volume 100
	Tinta amarelo = new Tinta(100, 0, 50, 0);
	//cria azul com volume 100
	Tinta azul = new Tinta(100, 0, 0, 50);
 
	//mistura azul com amarelo
	amarelo.pinta(azul);
 
	//verifica o resultado. O volume deve ser 200
	assertEquals(200, amarelo.getV());
	assertEquals(25, amarelo.getB());
	assertEquals(25, amarelo.getY());
	assertEquals(0, amarelo.getR());
}

Nós queremos tornar esse código mais claro, e para isso usaremos uma interface de intenção revelada. Mudaremos o código da classe Tinta e o nosso teste:

public void testMisturaDeTintas(){
	//cria amarelo com volume 100
	Tinta amarelo = new Tinta(100, 0, 50, 0);
	//cria azul com volume 100
	Tinta azul = new Tinta(100, 0, 0, 50);
 
	//mistura azul com amarelo
	amarelo.misturadoCom(azul);
 
	//verifica o resultado. O volume deve ser 200
	assertEquals(200, amarelo.getVolume());
	assertEquals(25, amarelo.getAzul());
	assertEquals(25, amarelo.getAmarelo());
	assertEquals(0, amarelo.getVermelho());
}
 
public class Tinta{
  private int vermelho;
  private int amarelo;
  private int azul;
 
  public void misturadoCom(Tinta p){
	volume = volume + pinta.getVolume(); //volume é somado
	//várias linhas de código complexo
	//para misturar tintas
  }
}

O código resultante já torna muito mais claro o que o método faz. O próprio nome do método (misturaCom) já diz: mistura uma tinta com outra. O antigo nome (pinta) não fazia sentido do ponto de vista do domínio, já que o cliente da loja de tintas quer saber: “que cor fica quando eu misturo essa tinta com outra?”

Projeto estratégico

As técnicas de criação e refinamento do modelo (como o uso da Linguagem Ubíqua e MDD) são importantes para começarmos a entender como desenvolver um sistema dirigido pelas regras de negócio do domínio, ou seja, como aplicar DDD. Mas a parte mais importante (e difícil) de Domain Driven Design é quando começamos a lidar com sistemas complexos. Como deve ser a interação entre sistemas que interagem entre si? Como dividir nosso trabalho, de maneira que foquemos nossos esforços naquilo que tem maior valor para o negócio? Como fazer a comunicação entre os times que desenvolvem esses sistemas?

Temos alguns padrões que nos ajudam a dividir nosso software em várias partes, que chamamos de contextos. Cada Contexto Delimitado deve estar bem claro para todos que estão envolvidos no processo de desenvolvimento. A fronteira entre contextos deve ser clara para todos, ou seja, todo mundo deve saber a qual contexto um determinado pedaço de código pertence.

Os padrões que nos ajudarão a estabelecer qual é a relação existente entre os vários times são:

• Mapa de Contextos – uma forma pragmática de documentar claramente os vários Contextos Delimitados que fazem parte de um sistema complexo (Figura 2). No mapa de contextos ressaltaremos os vários componentes do software e como as equipes que cuidam desse sistema interagem. Além disso, criaremos um mapa de tradução que servirá para facilitar a comunicação. Muitas vezes, existem termos usados para um mesmo conceito em vários contextos (por exemplo, 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). Toda vez que o time do sistema de cobrança for conversar com o time de faturamento, ele terá que usar adequadamente o termo “Nota Fiscal” para que o outro time entenda o que está sendo dito;

Figura 2. Mapa de Contextos

• Produtor-Consumidor – Quando os times possuem uma relação bem clara de Consumidor-Produtor. Produtor é o time que fornece software para o time Consumidor. Nesse tipo de relação, o Produtor assumirá compromissos de entregas para seu Consumidor, que por sua vez, tomará decisões esperando que esse compromisso seja cumprido. O time Produtor deverá rodar testes automatizados feitos pelo Consumidor (ou por ele mesmo) toda vez que fizer alguma alteração na interface que o cliente usa. Isso garantirá que nada irá quebrar do lado do Consumidor;
• Conformista – Algumas vezes não é possível que dois times de desenvolvimento se relacionem como Produtor-Consumidor. Mesmo que o Produtor tenha muito boa vontade, ele pode ter outras prioridades. Caso não seja possível alterar ou pedir alterações de uma parte do sistema mantida por outro time, deve-se adotar uma postura conformista e assumir que a única forma de caminhar é ter que aguardar o outro grupo e se adaptar a sua realidade. Quando a relação de conformista é estabelecida, não solicitamos mais funcionalidades ao outro time. Alteramos nossos sistemas para se adequar ao que já é oferecido pelo outro sistema;

• Núcleo Compartilhado – Quando dois times alteram uma mesma base de código comum (Figura 3). É importante que esse pedaço de código esteja bem definido e que possua muitos testes automatizados, que devem ser rodados por qualquer um dos grupos que desejar fazer alguma alteração. Todas as alterações devem ser comunicadas ao outro time e os testes precisam fazer parte de um processo de Integração Contínua. Quando se usa um núcleo compartilhado, esse pedaço de código tende a ser mais difícil de mudar, já que precisa da aceitação de várias equipes. Por outro lado, evita-se algumas duplicações, já que conceitos comuns são codificados uma única vez e utilizados por vários sistemas;

Figura 3. Núcleo Compartilhado

• 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 (Figura 4). 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;

Figura 4. Camada Anti-corrupção

• Caminhos Separados – Quando o custo de integração é muito grande e os benefícios pequenos, times podem decidir seguir caminhos em que dois sistemas não dependam um do outro. Esse padrão é muito usado principalmente em partes pequenas e periféricas do domínio. Um exemplo seria optar por ter um cadastro de CEP local num sistema de vendas online, ao invés de integrar com o sistema dos correios;
• Serviço Aberto de Funcionalidades e Linguagem Publicada – Quando temos vários clientes que interagem com uma mesma parte do nosso sistema, não é conveniente que criemos adaptações para cada um desses clientes. A solução para essa situação é criar um Serviço Aberto de Funcionalidades e criar uma Linguagem Publicada. Essa linguagem é a documentação de uma API que poderá ser usada pelos vários clientes. Hoje em dia, vários serviços de internet utilizam esse tipo de abordagem: Google, Flickr, Twitter, Amazon, etc. Todos esses serviços possuem API pública, que pode ser usada por programadores que queiram criar sistemas que interajam com esses serviços.

Em busca do Núcleo

A parte mais importante e que, de fato, torna o uso de DDD interessante, é o processo chamado de Destilação do Domínio. A perfeição é atingida quando não temos mais nada para tirar daquilo que chamamos Núcleo do Domínio (Core Domain). Inicialmente, o nosso sistema é um bloco monolítico, que mistura código de várias camadas, classes com especialidades bem diversas. Nosso trabalho é ir separando em módulos, refatorando, extraindo métodos, classes, conceitos. É preciso organizar tudo, de forma que tenhamos bem claro quais são os conceitos centrais do nosso negócio. Esses conceitos, centrais, são nosso núcleo.

Tudo que não fizer parte do núcleo deve ser extraído e separado em sub-domínios genéricos. Apesar de serem elementos que fazem parte do nosso domínio, não são centrais. Uma vez que conceitos secundários são identificados, deve-se dar menor prioridade para eles do que para aqueles elementos que estão no Núcleo do Domínio. Eventualmente, vale a pena considerar adotar soluções prontas (de prateleira) para esses casos, ao invés de manter a implementação sob responsabilidade do time de desenvolvimento. Um exemplo: imagine que estamos desenvolvendo um sistema para uma empresa de entregas internacionais. Nesse sistema temos que tratar com seriedade a questão de fuso-horários, já que esse assunto pode ser crucial para o agendamento e pontualidade nas entregas. Apesar disso, “fuso-horário” não é, provavelmente, um conceito que faz parte do núcleo do nosso negócio. Podemos desenvolver nosso próprio código de conversão de horários entre vários fusos, mas a melhor alternativa seria usar alguma biblioteca pronta. Provavelmente existe uma que irá atender às nossas necessidades.

Para tornar claro para todos o que é exatamente o Núcleo do Domínio, convêm escrever um documento pequeno, de no máximo uma página, com uma Sentença da Visão do Domínio.

Um exemplo de Sentença da Visão do Domínio seria:

“O modelo representa compras feitas por clientes numa loja. O cliente pode passear pela loja e visualizar produtos, que estão divididos em categorias. O cliente coloca os produtos que deseja num carrinho de compras e depois passa no caixa para efetuar o pagamento, que pode ser feito em dinheiro ou cartão. Após o pagamento, os produtos são oficialmente retirados do estoque da loja.”

Apesar de serem importantes, as especificações abaixo não fazem parte da visão de domínio:

“Todos os produtos são identificados por códigos de barra. Os códigos são lidos no caixa por um terminal e os preços são mostrados na tela, para o cliente, quando o código é lido. Os dados de compra são enviados através da rede sem fio e cadastrados num banco de dados, que deve ter 99,9% de disponibilidade.”

Algumas vezes, essa visão resumida não é suficiente para documentar todo o Núcleo. Outra forma de ressaltar as partes que fazem parte do coração do domínio é usar o padrão Núcleo Destacado. Para isso, criamos um documento mais extenso, mas que não passe de sete páginas, explicando todos os elementos do núcleo e a forma como esses elementos interagem. Também podemos definir um formato especial, destacado, para representar elementos do núcleo no modelo de domínio. Assim, qualquer pessoa que estiver olhando a documentação geral do modelo, saberá claramente quais elementos são fundamentais e quais não são.

Conclusões

Extrair a essência do domínio, dentre milhares de linhas de código de um sistema complexo nem sempre é fácil. O trabalho de refinamento e busca de uma visão clara é contínuo. A refatoração é um processo incessante de busca por melhorias de projeto. Observe a sequência de imagens da Figura 5. Essas imagens fazem parte um estudo feito por Pablo Picasso, que durou cerca de dois meses. Durante esse tempo, o pintor refez várias vezes o mesmo desenho do touro. A cada passo ele identificava partes do desenho anterior que poderiam ser removidas, sem que a essência da idéia fosse perdida. Aplicar DDD é utilizar Padrões com o objetivo de extrair e reconhecer a essência de um sistema.

Figura 5. Refatorando para compreender a essência

Os padrões citados nesse artigo são apenas alguns dos descritos em Domain Driven Design. DDD é uma forma de desenvolver software que, por estar ligado a boas práticas de Orientação a Objetos, tem muito a ver com desenvolvimento ágil. Além disso, a própria idéia de Padrões, que promove eficácia na comunicação, é um dos valores pregados pelos agilistas. Obviamente não é possível entender DDD lendo poucas páginas. O conselho que damos é ler o livro do Eric Evans e começar a aplicar esses padrões no seu próprio negócio. Certamente são técnicas que levarão ao desenvolvimento de serviços de qualidade, sistemas seguros e fáceis de dar manutenção, levando, consequentemente, à satisfação dos seus clientes com a rapidez que o mercado de hoje exige.

.De que se trata o artigo:

Neste artigo veremos os principais padrões de Domain Driven Design e alguns exemplos de como esses padrões podem ser aplicados.

Para que serve:

DDD induz a implantação de um cenário de melhoria contínua, podendo ser uma ferramenta extremamente útil para se desenvolver software de qualidade e que atenda bem as necessidades do cliente.

Em que situação o tema útil:

Tanto programadores quanto arquitetos e especialistas de negócio podem se beneficiar das técnicas de DDD, que ensinam justamente boas práticas de como modelar seu domínio, além de tornar eficiente a interação entre os vários papéis de pessoas que fazem parte do processo de desenvolvimento de software. DDD pode ser muito útil quando vários times desenvolvem um mesmo sistema complexo.

Links

Mini-book de DDD

http://www.infoq.com/minibooks/domain-driven-design-quickly

Domain Driven Design

http://domaindrivendesign.org/

Vídeo de Introdução a DDD

http://vimeo.com/3545313

Vídeos sobre Projeto Estratégio

http://vimeo.com/3972348

http://www.infoq.com/presentations/strategic-design-evans

Vídeo Colocando o Modelo para Funcionar

http://www.infoq.com/presentations/model-to-work-evans

Eric Evans, Domain Driven Design – Tackling Complexity in the Heart of Software, 2004.

Há algum tempo venho enrolando para publicar a minha dissertação de mestrado. O motivo dessa enrolação é bem simples: eu não terminei de revisar a dissertação. Foram vários e vários comentários que a banca fez no dia da defesa e que eu tinha que alterar no texto.

• A primeira fala sobre Padrões para Introduzir Novas Ideias, como foi a utilização deles na implantação de métodos ágeis na Locaweb.
• A segunda fala sobre as relações entre Arte e o Desenvolvimento de Software e faz o link com a primeira parte com o padrão ‘Faça Arte’

Como eu disse, ainda faltam fazer as últimas alterações sugeridas pelo meu orientador. Continuo aceitando sugestões e críticas de todos. Se ninguém me escrever nada, poderá ser por 2 motivos:

1. Ninguém leu o texto
2. O texto está perfeito

Como sou um homem livre e de bons costumes, caso ninguém mesmo comente, vou assumir o segundo como verdade…