A análise e modelagem de software não é uma atividade simples, quando o domínio do software não é algo trivial e mais complicado ainda. O Domain Driven Design sugere uma nova abordagem para resolver estas tarefas, criando uma linguagem única para todas as pessoas envolvidas no projeto. Nesta palestra buscamos conhecer um pouco mais sobre essa abordagem e quais ferramentas temos para aplicá-la utilizando PHP.

1. DDD e PHP
Luís Otávio Cobucci Oblonczyk
25 de Agosto de 2012

2. Luís Otávio Cobucci Oblonczyk
●
Evangelista (doido por) PHP
●
Desenvolvedor na Softnex Tecnologia (SC)
●
Membro do PHPSC
●
ZCE PHP 5.3
●
Perfeccionista ao extremo =P
@lcobucci
http://about.me/lcobucci

4. Fácil aprendizado

5. Inúmeros exemplos
Fácil aprendizado

6. Inúmeros exemplos
Comunidade ativa
Fácil aprendizado

7. mu
Inúmeros exemplos
ito
Comunidade ativa
Fácil aprendizado

8. mu
Inúmeros exemplos
ito
Comunidade ativa
Diversas opções
de frameworks
para facilitar a Fácil aprendizado
vida

9. Aprendizado 100% prático, $$$ garantido!

10. Será?

11. Conceito ou (infra)estrutura?

12. Possíveis resultados...

13. O que é DDD?
“Domain-driven design (DDD) is an approach to
developing software for complex needs by deeply
connecting the implementation to an evolving
model of the core business concepts.
(...)
Domain-driven design is not a technology or a
methodology.”
http://en.wikipedia.org/wiki/Domain-driven_design

14. Definições básicas
Domínio: área de conhecimento, influência ou
atividade;
Modelo: conjunto de abstrações que descrevem
os aspectos de um domínio;
Linguagem onipresente: linguagem estruturada
com base no modelo e utilizada por todos os
membros da equipe.

15. Linguagem onipresente
evita desentendimentos.

16. Requisitos do DDD
●
Domínio não é trivial
●
A equipe tem conhecimento técnico e
experiência em desenvolvimento com
orientação à objetos (paradigma mais indicado)
●
A equipe possui acesso ao analista de negócio
●
O processo de desenvolvimento é iterativo

17. Camadas de softwares
Softwares podem ser divididos em várias
camadas. Eric Evans diz que “a maior parte das
arquiteturas bem-sucedidas são variações de
quatro camadas conceituais”:
●
Camada de apresentação (UI);
●
Camada da aplicação;
●
Camada do domínio;
●
Camada da infra-estrutura

18. Camada de apresentação
“Responsável por mostrar informações e
interpretar os comandos do usuário.
Onde o agente externo pode ser outro sistema de
computador em vez de um ser humano.”

19. Camada da aplicação
“Define as funções que o software deve executar
e direciona os objetos expressivos do domínio
para resolver os problemas.”
“Ela não contém as regras ou o conhecimento do
negócio, apenas coordena tarefas e delega
trabalhos.”

20. Camada do domínio
“Responsável por representar conceitos do
negócio, informações sobre a situação e as regras
do negócio.”
“Esta camada é o coração do software”

21. Camada de infra-estrutura
“Fornece recursos técnicos genéricos que
suportam as camadas mais altas.”
“A camada de infra-estrutura pode também
suportar o padrão de interações entre as quatro
camadas através de um framework arquitetural.”

22. Tipos dos objetos
O DDD divide o domínio em vários tipos de
objetos diferentes, cada qual com sua
responsabilidade definida.

23. Entidades

24. Entidades
Objetos que possuem identificação única dentro
do contexto em que ele se aplica, ou seja, para o
domínio do software é fundamental que possua
uma identidade (é único). Basicamente é o lar das
regras de negócio de um software.

25. Objetos de valor

26. Objetos de valor
São objetos que participam das regras de negócio,
entretanto são imutáveis e sua identidade não é
relevante. De modo geral, eles apenas
armazenam e transmitem valores.

27. Serviços

28. Serviços
Centralizam e organizam as chamadas às
operações das regras de negócio, ou seja, não
possui o conhecimento sobre o funcionamento do
software, porém realiza a ligação entre os objetos
que conhecem. Basicamente são Façades.

29. Agregados

30. Agregados
Grupos de objetos associados que são tratados de
forma única. Os objetos são relacionados a uma
raiz e delimitam um limite. A raiz é normalmente
uma ENTIDADE e os objetos associados podem
ser outras ENTIDADES ou OBJETOS DE VALOR.
A raiz restringe o acesso externo aos objetos do
limite, portanto possui a lógica necessária para o
gerenciamento dos mesmos.

31. Fábricas

32. Fábricas
Tratam da construção dos objetos (normalmente
entidades e objetos de valor), seu objetivo
principal é simplificar a complexidade da criação
dos objetos (e seus agregados).
Podem ser objetos separados (builders) ou até
métodos dentro da definição da class (factory
methods).

33. Repositórios

34. Repositórios
Abstraem o acesso às camadas de persistência
(pertencentes à camada de infra-estrutura).
O objetivo principal é dar a impressão que é uma
grande coleção de objetos, e que tudo está em
memória.

35. Repositórios
Abstraem o acesso às camadas de persistência
(pertencentes à camada de infra-estrutura).
O objetivo principal é dar a impressão que é uma
grande coleção de objetos, e que tudo está em
memória.
Repository != DAO

36. Então tudo é conceitual?
Exato!
A questão principal é como nós organizamos o
nosso software, e principalmente como nós
lidamos com a nossa equipe e com os clientes.
Lembrando sempre de manter a linguagem
onipresente!

37. Cadê o PHP no meio disso tudo?

38. Domain Driven Design e PHP
O DDD não restringe sua abordagem a nenhuma
linguagem, mas a maioria dos exemplos dados nas
referências são construídos em Java.
Existiu um costume de tentar limitar a ação do
PHP para apenas websites, e a cada versão nova
do PHP esta tentativa é cada vez mais destruída.
Nas versões oferecidas há tempo já existem todos
os recursos necessários para seguir os conceitos
do DDD.

39. PHP e OOP
Como não é novidade pra ninguém, o PHP está
melhorando cada vez mais seu suporte à
orientação à objetos (sem perder sua flexibilidade
de linguagem dinâmica e suporte a outros
paradigmas de programação).
Uma das alterações revolucionárias (por ter
movimentado demais a comunidade) é a inclusão
de namespaces (a partir da versão 5.3).

40. PHP e OOP
Em função das facilidades que o orientação à
objetos nos proporciona para ter uma
aproximação mais real do domínio (e
principalmente dos termos que ele traz –
linguagem onipresente), este é o paradigma ideal
para utilizarmos.

41. Algumas ferramentas que auxiliam...

42. Ferramentas disponíveis
Com a versão 5.3, também vieram grandes
ferramentas que nos ajudam muito no
desenvolvimento, principalmente:
●
Doctrine 2 http://www.doctrine-project.org/
●
Symfony 2 http://symfony.com/

43. Doctrine 2
O Doctrine 2 é um framework PHP que provê dois
grandes subprojetos: Doctrine DBAL (Database
abastraction layer) e Doctrine ORM.
Uma funcionalidade que ele proporciona é a
classe DoctrineORMEntityRepository que
possibilita a criação de repositórios customizados
(que se encaixam muito bem no conceito de
Repositórios do DDD).

44. Symfony 2
Full stack framework organizado em
componentes para as diversas necessidades de
uma aplicação, com destaque principal nos
componentes:
●
Dependency Injection
●
HTTP Foundation

45. Pequeno jabá =P

46. ActionMapper 2
Micro framework que utiliza componentes do
Symfony 2 e do Doctrine 2 para realizar as tarefas
de front-controller.
Facilita bastante a criação de aplicativos que
seguem DDD em função de não forçar a
organização do seu projeto.
Mais info: http://lcobucci.github.com/action-mapper/
Exemplo: http://conf.phpsc.com.br
https://github.com/PHPSC/phpsc-conf

47. Conclusões
Os conceitos do Domain Driven Design oferecem
a possibilidade de modelarmos nosso software de
acordo com as regras de negócio do cliente,
buscando SEMPRE manter a mesma linguagem de
comunicação entre TODAS as pessoas envolvidas.
Para o PHP traz uma nova visão de como
estruturar as aplicações criadas, quebrando os
preconceitos existentes em torno da linguagem.

48. “Para tudo, mas principalmente na
análise das regras de negócio, lembre-se:
o que é implícito não é explícito”
Albert Einstein

49. Maiores informações

50. Obrigado!
Eu por aí: http://about.me/lcobucci
Slides: http://slideshare.net/lcobucci