Entenda o Domain Driven Design

Olá amigos e amigas tudo bem? Hoje vou resumir de uma forma mais "Mamão com açucar" O que é o DDD e imaginar exemplos utilizando o DDD para como resolver um determinado problema ok?

Provavelmente vc se lembra daqueles 3 gordinhos da Embratel não é? "pegue o seu d d dedo e disque o nu número da embratel, antes do ddd é 021..." Pois bem, eles não tem nada haver com o que eu vou explicar, mas fica ai como imagem de apresentação.


Existem duas maneiras de vc ter caído aqui no meu blog, a 1ª é vc conhecer meu blog e veio aqui para ver novos artigos(a grande menoria). A 2ª é pq vc está pesquisando sobre DDD e encontra muito artigo cheio de filosofia e acaba não absorvendo muito bem, e provavelmente vc não tem muito tempo para lêr o livro do Evans então chegas mais que vou resumir essa parada pra vc!

Antes de mais nada vamos ao entendimento básico, Domain Driven Design significa entre outras palavras Projeto Orientado a Domínio. Que veio do título do livro do Eric Evans. O livro do Evans é basicamente um catálogo de padrões baseados em experiências do próprio Evans ao longo de mais de 20 anos de desenvolvimento de software utilizando técnicas de Orientação a Objetos.

O DDD é basicamente o uso ideal da Orientação a Objetos(PRONTO ACABEI DE EXPLICAR TUDO PODE IR EMBORA).

Não fique bravo(a) comigo pois essencialmente é isso mesmo, DDD é o uso inteligente da orientação a objetos para resolver diversos problemas.

Vamos lá open your mind.

Os decoradores(entende-se pessoas que decoram) de Orientação a Objetos tem um problema grave com isso pois quando se fala em OO as primeiras coisas que vem na mente são "classes, herança, polimorfismo, encapsulamento, lalala...". Mas essa são as regras básicas e técnicas da OO, a grande sacada dela está em independência de tecnologia, mínimo de acoplamento, reutilização de código, alinhamento do código com o negócio, coerência em problemas reais... Olha só, agora sim estamos falando de OO resolvendo problemas reais e essa é a essencia campeonato(entende-se campeão).
 

Vamos ter um papo sério sem muita filosofia esse não é um artigo é mais uma conversa ok? Então vamos pensar, o Projeto Orientado a Domínio é essencialmente entendermos o negócio e tornar o código lógico a esse negócio, coeso a esse negócio, aquele papo de entity não pode ter lógica é justamente o OPOSTO do DDD pois sim vamos ter uma camada de domínio cujo qual minhas entidades são inteligentes! Separar a lógica em serviços que manipulam as entidades muitas vezes torna o reuso impossivel e é basicamente dizer eu sou um macaco que batuco o teclado com a intenção de gerar código....

O DDD não vai exatamente te impor como vc faz a arquitetura do seu software mas sim te abrir a mente sobre como dar funções para quem realmente merece afinal, vc não mandaria um engenheiro fazer uma cirurgia plástica não é?

Veja um exemplo do DDD por "cima":



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.


O DDD basicamente começa por essa premissa básica de conhecer de fato o domínio, mas ele é muito mais amplo e mais complexo por isso eu tentei aqui dar a introdução desse mundo partindo do principio de entender essa ideia.

Existem alguns pontos importantes abordados no DDD que são o uso da mesma linguagem, evitar traduções indevidas, quebrar o problema em camadas, entender entidades, agregados, objetos de valor, fábricas, serviços, repositórios, módulos entre outros.


Segue aqui a primeira versão de um slide da minha palestra sobre Domain Driven Design

Domain Driven Design no PHP from Paulo Victor Gomes

Caso vc queira se aprofundar nos estudos então é melhor ler o livro do Evans http://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780321125217



Até a próxima.

Desenvolvimento ágil com XP (Extreme Programming)

Amigos e amigas hoje vou falar um pouco sobre mais uma metodologia ágil de desenvolvimento (a mais conhecida) XP.
XP nesse caso não é aquele sistema operacional da microsoft ok? Mas sim as siglas de EXTREME PROGRAMMING traduzindo Programação extrema

Talvez você esteja se perguntando; "Será que para desenvolver uma aplicação de maneira rápida eu vou precisar de um capacete e uma luva?" 

A resposta é não, mas se você quiser utilizar, eu acredito que os acessórios pouco importa com tanto que vc esteja preparado para a agilidade do XP rsrs...

Pv... me explica por favor oq é esse XP? XP significa Programação extrema (do inglês eXtreme Programming), ele é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança, ou seja a melhor escolha para o mundo hoje em dia não acham? Na maioria dos casos os requisitos sempre são alterados e assim não é possível trabalhar sempre em cima de uma base de análise pois o que foi planejado ontem pode ser alterado, hoje em dia desenvolvimento de sistemas não é como antigamente em que um software era engessado.

Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Breve histórico
Nascida nos Estados Unidos ao final da década de 90 por Kent Beck. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

O XP assim como outras metodologias faz parte do Manifesto ágil um manifesto iniciado nos Estados Unidos em que se prega novos e interessantes valores para o desenvolvimento de software como por exemplo:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Perceba que o manifesto ágil busca uma outra visão no desenvolvimento de software, busca a criação de um projeto de forma ágil e o que é muito importante falar atendendo expectativas.

TA MAS COMO UTILIZAR O XP?

'Utilizar' o XP no desenvolvimento de um projeto é mais fácil e simples do que parece basta entender seus valores e princípios e assim aplica-los no desenvolvimento.

Princípios básicos
Para o desenvolvimento ágil, é necessário entender que essa metodologia se baseia em principios básicos que são:

• Feedback rápido
• Presumir simplicidade
• Mudanças incrementais
• Abraçar mudanças
• Trabalho de alta qualidade

Ou seja é necessário feedback rápido da situação do desenvolvimento, módulos e funcionalidades tanto para o cliente como para a equipe. Programar, desenvolver e resolver problemas  complexos é uma tarefa perigosa pois para um problema pode ser encontrado diversas soluções mas qual é a melhor? A melhor é a mais simples, aquela clara e explicita por isso presumir simplicidade. Mudanças acontecem normalmente e devem ser encaradas e analisadas por isso Mudanças incrementais, as mudanças são bem vindas e é necessário abraça-las mas com um bom planejamentos por isso Abraçar mudanças e por ultimo desenvolver algo deve ser levado a sério, deve-se buscar a máxima excelência e qualidade no trabalho.

Valores
Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), existe uma atenção principal no escopo. 

Por isso, recomenda-se priorizar funcionalidades que representam maior valor possível para o negócio, ou seja trabalhar na regra de negócio principal do software. E assim se for necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

Práticas
Para aplicar esses valores e princípios no desenvolvimento, o XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

Jogo de Planejamento (Planning Game):

O desenvolvimento é feito em ciclos semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. O nome dessa reunião é Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores dão um prazo provavel. A principal peça desse 'jogo' é o cliente pois ele define funcionalidades, fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

Pequenas Versões (Small Releases): Liberar versões funcionais auxilia muito na aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.

Metáfora (Metaphor): Busca facilitar o entendimento na comunicação com o cliente, por exemplo um processo de 2 semanas para um advogado é algo rápido, enquanto que gerar boletos em 2 semanas é algo extramamente lento para um banqueiro, e ambos são lentos para um select que um programador espera o retorno. Sendo assim o intuito dessa prática é entender o que algo significa para o cliente.

Projeto Simples (Simple Design): Simplicidade é um príncipio da XP, ou seja fazer conforme a necessidade manda, buscando clareza e padronização. Desenvolver simples significa pensar claro, alcançar objetivos e otimizar sempre a realização. Por exemplo se você pretende reutilizar uma classe Pessoa com um método Programar pense bem e veja se não é melhor criar uma classe Programador que extenda da Pessoa e assim colocar esse método pois um programador é uma pessoa mas só ele programa, uma pessoa é uma pessoa e nem sempre ela programa. Atingir o objetivo simples e desenvolver com lógica faz parte desse princípio.

Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.

Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

Programação em Pares (Pair Programming): é a programação em dupla ou seja, duas pessoas em um computador, normalmente um é o 'piloto' e o outro o 'co-piloto' os dois desenvolvem juntos sendo que um fica codificando e o outro analisando e falando, assim é a atenção de duas pessoas em um desenvolvimento garantindo muitas vezes boa qualidade, e ganho de tempo pois os dois estão focados em um objetivo, assim um puxa o outro.

Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

Desenvolvimento Orientado a Testes (Test Driven Development): Conhecido como TDD onde primeiro se cria os testes unitários (unit tests) e depois cria-se o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;

Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Conclusão
A XP é uma metodologia que é um reflexo do mundo hoje em dia, padronizar, agilizar, melhor e atender são objetivos que as práticas e valores do manifesto ágil busca atingir e a metodologia mais estável e renomada para isso é a XP.

Referências

Agile Software Development, Principles, Patterns, and Practices (ISBN 0135974445)

Extreme Programming Explained: Embrace Change (2nd Edition) (ISBN 0321278658)

UFA! Essa é a base do XP. Obrigado pela atenção e até a próxima!

Scrum metodologia ágil de desenvolvimento

Olá meus amigos e amigas tudo bem? Hoje vou falar sobre algo que poucos conhecem mas é de tremenda importância no desenvolvimento de sistemas, hoje vou falar do SCRUM

Afinal o que é esse tal de SCRUM que tanto análista desenvolvedor fica se gabando? E porque essas pessoas do Rugby ai na imagem?
A resposta para isso é simples; Scrum é uma metodologia ágil para gerência em desenvolvimento de software, permite manter o foco na entrega do maior valor de negócio, no menor tempo possível.

Com o tempo notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos) por isso a foto do 

Rugby.

Como podemos perceber nessa introdução o grande objetivo do SCRUM é agilidade no desenvolvimento CORRETO de projetos de software e para que isso fique mais claro vamos mostrar aspectos funcionais do SCRUM.

O SCRUM é baseado em ciclos de 30 dias chamados Sprints, onde se trabalha para alcançar objetivos bem definidos. Estes objetivos são representados no Product Backlog, uma lista de coisas para fazer que é constantemente atualizada e repriorizada.

Os papéis do SCRUM

Equipe: A equipe é responsável por entregar soluções, geralmente é formada por um grupo pequeno (de 5 a 9 pessoas) e que trabalha de forma auto-gerenciada ou seja, eles mesmo se gerenciam.

Product Owner: Responsável pela visão de negócios do projeto, é ele quem define e prioriza o Product Backlog.

Scrum Master: Uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de SCRUM estão sendo executadas com eficiência. Em outras palavras é ele que faz o 'meio de campo' entre programadores e gerentes, programadores e clientes... programadores e o MUNDO rsrs...

Funcionamento do SCRUM

Imagem ilustrativa do SCRUM

Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. 
Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. 
Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.

Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser entregues são agora tratados no Sprint Backlog. As tarefas agora são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas, ou seja o programador/desenvolvedor agora é o deus seguido da decisão.

Reuniões Diárias: o Scrum Master se reune diariamente com a Equipe num mesmo horário, para que se reporte:

O que foi feito ontem?

O que se pretende fazer hoje?

Quais são os impedimentos que estão atrapalhando a execução das tarefas?

Revisões: no final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint.


Ou seja o SCRUM garante um giro rápido uma vez que não existe pressão mas sim um 'fatiamento' de necessidades e prioridades.


E ai gostou? Quer passar a implementar em sua empresa? Projeto?
Quer conhecer mais? Clique aqui para ver um pouco mais sobre SCRUM (um pdf completo).




Espero que eu tenha ajudado. 


PS: A escolha dos papéis variam da equipe, não existe CHEFE no SCRUM mas sim um grupo unido.