Tag: Eric Evans

Categories
Carreira

Como anda o seu inglês?

Há não muito tempo uma pessoa me procurou no IM para conversar sobre sua carreira. Ela me disse que no momento estava fazendo um curso de Java e me perguntou o que exatamente ela precisava para trabalhar numa empresa como o Yahoo!. Conversamos sobre algumas coisas até que perguntei sobre seu inglês. Para minha surpresa, ela disse que o curso de inglês iria ter que esperar um pouco porque naquele momento ela estava priorizando o curso de Java…

Se você está numa situação parecida, faça o seguinte: pare tudo que você está fazendo e vá aprender inglês. Sério, no nosso mercado é muito, mas muito mais importante do que você pode imaginar.

Em primeiro lugar, alguns dos melhores livros existentes só estão disponíveis em inglês. Poucos títulos são traduzidos e quando são levam alguns meses (ou anos) para tal, isso sem contar que as traduções muitas vezes são ruins. Por exemplo, o Domain-Driven Design do Eric Evans levou aproximadamente 5 anos para ser traduzido, o Patterns of Enterprise Application Architecture do Martin Fowler levou 4 anos, e por aí vai. Hoje em dia o tempo é menor que isso, mas mesmo assim é muito tempo. Ou seja, você não só vai ficar alguns meses (ou anos) para trás como também corre o risco de não ter acesso a uma boa parte do conteúdo mais relevante disponível.

Em segundo lugar, os grandes players de TI publicam seus blogs em inglês – assim como vários dos desenvolvedores mais influentes no mercado. De forma alguma estou desmerecendo os blogs em português (como esse aqui), mas grandes nomes como Robert Martin, Alistair Cockburn, Kent Beck – e mais algumas dezenas que eu poderia citar – escrevem em inglês. Isso sem contar as dúzias de blogs como o TechCrunch, Mashable, High Scalability ou até mesmo o xkcd. Se você não entende inglês você não poderá aproveitar todo esse conteúdo.

Em terceiro lugar, a maioria dos projetos Open Source relevantes são em inglês. Por exemplo, você está acompanhando o desenvolvimento do Node.js? Você já estudou Clojure? E o Rails 3? Linux? Python? Projetos da Apache Foundation? Se você já brincou com alguma dessas coisas (ou todas) certamente foi porque você sabe inglês. E você pode não somente usar essas coisas para desenvolver como também estudar os códigos para entender como funcionam ou contribuir com os projetos. Enfim, um mundo gigantesco de oportunidades.

Eu poderia dar mais um monte de motivos – como dizer que a maioria dos lugares mais relevantes que todo mundo gostaria de trabalhar vão exigir que você saiba inglês – mas acho que só isso já é mais do que suficiente. Inglês é uma das coisas mais essenciais para profissionais de desenvolvimento de software e você não pode ignorar isso. Corra atrás e aprenda inglês “pra ontem”, essa é sua prioridade número um!

Categories
Domain-Driven Design

Síndrome de DAO

O assunto Repository X DAO já está bem batido, eu sei, mas é impressionante como isso confunde muita gente até hoje… Muitas pessoas já postaram sobre isso mas eu quero dar meus dois centavos.

Com a popularização do Domain-Driven Design ví muita gente simplesmente renomeando seus XptoDAO para XptoRepository achando que assim estariam aplicando DDD porque “chamar um objeto de Repository é mais semântico que DAO”. Esses dias no Twitter ví uma mensagem assim: “Repositório ou DAO ? Eu gosto do nome repositório porque me parece ser uma abstração mais adequada”. Vamos lá, não se trata somente de nomes diferentes para a mesma coisa.

O padrão DAO têm o objetivo de criar uma abstração da infra-estrutura de armazenamento de dados para a aplicação. Uma camada de persistência é útil porque dá a funcionalidade de armazenamento/persistência de dados sem revelar detalhes específicos da infra-estrutura por trás disso. O armazenamento pode ser feito num banco de dados, em vários bancos de dados, em um webservice, em um arquivo texto, tanto faz, mas do ponto de vista da camada de negócios que obtém esses dados, por exemplo, ela está lidando apenas com busca, alteração e gravação de objetos em algum lugar que nem importa.

Já o padrão Repository tem o objetivo de dar apoio ao domain model fornecendo persistência. Ao contrário do DAO, que é um objeto de infra-estrutura da aplicação e faz parte da camada de persistência, o Repository faz parte do domain model que é parte da camada de negócios.

Domain models (modelos de domínio) fazem sentido quando a aplicação tem regras de negócio muito complexas. Isolar as regras de negócio em um domain model torna mais fácil o trabalho de focar e lidar com essas regras complexas. Porém, para que um software possa funcionar fortemente baseado em domain model (que é a proposta de Domain-Driven Design) é necessário dentre outras coisas que haja algum componente que faça parte desse modelo e permita que se faça persistência de dados – e daí veio o Repository.

No ano passado conversei bastante com o pai do DDD – Eric Evans – sobre isso e para ele o problema é que as pessoas confundem esses dois conceitos porque realmente são bem parecidos. Na maioria dos casos você irá precisar dos dois, porque o domain model fará buscas por objetos em um Repository que por sua vez delegará para o DAO, que é quem entende como é a infra-estrutura de armazenamento de dados. Para ele também não importa se o Repositório é uma classe ou uma interface, o que importa é que os objetos do domain model deverão dempre lidar com busca e persistência de objetos usando a interface do Repository, que tem o compromisso de ser mais semântica do que a do DAO.

Categories
Carreira

Você tem que ler os livros!

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert […] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

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
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!