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.

Modelo de Documentação de Software

Já que eu andei falando muito de engenharia de software nada melhor do que montar um artigo que explicasse de uma vez por todas a diferença entre DOCUMENTAÇÃO DE SOFTWARE e UML e ainda liberasse um modelinho de documentação para download (atenção amigos, esse modelo é generico, o ideal seria vc adapta-lo para melhor atender o seu projeto. Mas acho que ele te da um bom 'norte' de como fazer, como se fosse um framework para documentar [NOSSA! APELEI])...

A verdade é que uma das coisas mais comuns na TI é as pessoas misturarem as coisas, isso é muito comum principalmente nos países latino-americanos em que queremos fazer primeiro e aprender depois (não que eu seja exceção[estou me referindo a exclusão])...

E por conta disso distorcemos alguns paradigmas importantes para desenvolvimento de software...

Veja bem, a cada 10 empresas de TI quando falamos a palavra documentação 6 pensam em UML, 1 pensa em documentação completa do projeto de software e as outras 3 não sabem o que é isso.

Associar UML a documentação não é um pecado, mas é algo incompleto pois uma documentação de sistemas é muito mais que um diagrama de caso de uso ou um diagrama de classe... Esses na verdade são complementos para uma boa documentação visto que eles foram criados em fase de modelagem do sistema e fazem parte sim da documentação do mesmo mas, sozinhos são uma penca de diagramas "sem sentido"... Ou você acha que é só fazer diagramas e pronto modelou e documentou?

Ta ta se vc for um gerente de projeto, analista de sistemas ou conhecedor de projetos de software talvez esteja se perguntando "ta, mas me explica o que é uma maldita documentação", e eu respondo; "uma documentação é uma documentação, ha! =)" e ai vc se atrapalha muito mais... e esse é meu objetivo... te atrapalhar para te mostrar o verdadeiro 'caminho das pedras'...

Vamos levar ao pé da letra... Eu sou uma pessoa(pelo menos no papel) e quando alguém pede minhas documentações o que eu faço? RG, CPF, Titulo de eleitor e etc... ou seja, tudo que me identifica como eu em texto/figura etc... com o software também é assim, imagine um sistema como um todo;

            Modelagem de dados, Regra de negócio, manuais do usuario, documentos de trabalho, commits, diagramas, comentários, código, mer...

No processo de desenvolvimento indiretamente vamos montando documentos do software criado (formalmente ou informalmente) e todos eles levam SIM a característica de documentação... então a questão não é exatamente o que é documentação mas sim "o que devo selecionar como documentação?". E é ai que começamos a parte funcional da coisa...


Por que precisamos de uma documentação? Qual o seu uso?
Meio de comunicação entre os membros de  um grupo de desenvolvimento;
Informações para as pessoas que venham a  fazer manutenção no sistema;
Informações à gerência de modo a ajudar a  planejar, fazer o orçamento e o cronograma;
Informações para ensinar aos usuários como  utilizar e administrar o sistema

E quais são os tipos de documentação?

De forma geral são 2, do processo e do produto.

• Documentação do processo 
  É produzida para que o processo de desenvolvimento do software seja administrável . Registram os processos de desenvolvimento e manutenção do software .
• Documentação do produto  
  Descreve o software que está sendo desenvolvido. É muito utilizada depois que o sistema é implementado, mas é essencial também para a  administração do processo de desenvolvimento.

Existe ainda uma explicação muito detalhada desses dois tipos de documentação mas acho que isso é o bastante para vc que esta com pressa e precisa do modelo.

Estou colocando aqui para download um modelo de documentação.

1º Modelo - Modelo leve para download (apenas a estrutura de diretórios)

2º Modelo - exemplo para download (esse contem uns exemplos)

ATENÇÃO PESSOAL! EU ANDEI RECEBENDO UNS E-MAILS DIZENDO QUE O MODELO DE DOCUMENTAÇÃO ESTAVA VAZIO, QUE SÓ TINHAM PASTAS.... A PROPOSTA INICIAL É JUSTAMENTE ESSA, APENAS MONTAR A ESTRUTURA DE DIRETÓRIO... MAS JÁ QUE O PESSOAL PEDIU EU MONTEI UM SEGUNDO MODELO PARA FACILITAR O ENTENDIMENTO.

Referências importantes

The UML is Not Sufficient (Scott Ambler)
http://www.agilemodeling.com/essays/realisticUML.htm

Muitos e muitos artigos do Martin Fowler
http://martinfowler.com/

UML - Diagramas

Bom dia! E como eu prometi hoje estou iniciando o segundo post sobre UML onde vou falar por cima um pouco sobre cada diagrama e nos outros posts explicar um a um com exemplos na prática...

Aliás, um feliz 2012 a todos, muita paz, saúde, sucesso e acima de tudo! CONHECIMENTO :]

Diagrama de casos de uso
Ele é o diagrama mais geral e informal da UML, sendo utilizado normalmente nas fases de Levantamento e Análise de Requisitos do sistema, e normalmente é sempre consultado duranto o processe de modelagem e serve como base para outros diagramas. Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma idéia geral de como o sistema irá se comportar.
Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial), que utilizarão de alguma forma o software, bem como os serviços, ou seja, as opções, que o sistema disponibilizará aos atores, conhecidas neste diagrama como Casos de uso.

Um exemplo:

Diagrama de classes
O mais utilizado e o mais importante da UML, servindo de apoio para a maioria dos moutros diagramas. Como o próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos possuídos por cada classe, além de estabelecer como as classes se relacionam e trocam informações entre si.

Diagrama de Objetos
Esta associado ao diagrama de classes. Na verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes, sendo bastante dependente deste. O Diagrama de Objetos fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classes em um determinado momento da execução de um processo do software. Este foi um dos diagramas tornados independentes pela UML 2, apesar de já existir anteriormente, era considerado apenas uma extensão do Diagrama de Classes.

Diagrama de estrutura composta
Descreve a estrutura interna de um classificador, como uma classe ou component, detalhando as partes internas que o compõem, como estas se comunicam e colaboram entre si. Também é utilizado para descrever uma Colaboração onde um conjunto de instâncias coopéram entre si para realizar uma tarefa. Este é um dos três novos diagramas propostos pela UML 2.

Diagrama de sequencia
Preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. Em geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome e apóia-se no Diagrama de Classes para determinar os objetos das classes envolvidas em um processo. Um Diagrama de Sequência costuma identificar o evento e determina como o processo deve se desenrolar e ser concluído por meio da chamada de métodos disparados por mensagens enviadas entre os objetos.

Diagrama de colaboração
Chamado de Diagrama de Comunicação na UML 2 esse diagrama está amplamente associado ao Diagrama de Sequencia, na verdade, um complementa o outro. As informações mostradas no Diagrama de Sequencia, porém com um enfoque diferente, visto que este diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os objetos estão vinculados e quais as mensagens trocam entre si durante o processo.

Diagrama de Gráfico de Estados
Chamado de Diagrama de Máquina de Estados na UML 2 procura acompanhar as mudanças sofridas por um objeto dentro de um determinado processo. Como o Diagrama de Sequencia, o Diagrama de Máquina de estados muitas vezes baseia-se em um Caso de Uso descrito em um Diagrama de casos de uso e apoia=se no diagrama de classes. O diagrama de maquina de estados é utilizado normalmente para acompanhar os estados por que passa uma instancia de uma classe, no entanto pode ser utilizado para representar os estados de um caso de uso ou mesmo os estados gerais de um sub-sistema ou de um sistema completo.

Diagrama de atividades
O diagrama de atividades era considerado um caso especial do antigo Diagrama de Gráfico de EStados, atualmente conhecido como DIagrama de Máquina de Estados, conforme foi descrito na seção anterior. A partir da UML 2.0 o DIagrama de Atividades foi considerado independente do DIagrama de Máquina de EStados. Esse diagrama preocupa-se em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes representada por um método com um cetro grau de complexidade e não de um processo completo como é o caso dos DIagramas de Sequencia ou Colaboração, embora também possa ser utilizado para este fim. O diagrama de Atividades concentra-se na representação do fluxo dle controle de uma atividade.

Diagrama de componentes
Esta amplamente associado à linguagem de programação que será utilizada para desenvolver o sistema modelado. Esse diagrama representa os componentes do sistema quando este for ser implementado em termos de módilos de código-fonte, bibliotecas, formulários, arquivos de ajuda, etc. e determina como esses componentes estarão estruturados e interagirão para que o sistema funcione de maneira adequada.

Diagrama de implantação
Determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado.

Diagrama de pacotes
Tem como objetivo representar os sub-sistemas englobados por um sistema de forma a determinar as partes que o compõem. Pode ser utilizado de maneira independente ou associado com outros diagramas.

Diagrama de interação geral
Uma variação do Diagrama de Atividades que fornece uma visão geral dentro de um sistema ou processo de negócio. Esse diagrama passou a existir somente a partir da UML 2

Diagrama de tempo
Descreve a mudança no estado ou condição de uma instância de uma classe ou seu papel durante um tempo. Tipicamente utilizada para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos. Esse é o terceiro diagrama criado a partir da nove versão da linguagem.

continua...