DDD e PHP - TDC 2012

Preview:

DESCRIPTION

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.

Citation preview

DDD e PHPDDD e PHP

Luís Otávio Cobucci Oblonczyk

25 de Agosto de 2012

Luís Otávio Cobucci OblonczykLuí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

Fácil aprendizado

Fácil aprendizado

Inúmeros exemplos

Fácil aprendizado

Inúmeros exemplos

Comunidade ativa

Fácil aprendizado

Inúmeros exemplos

Comunidade ativamuito

Fácil aprendizado

Inúmeros exemplos

Comunidade ativa

Diversas opçõesde frameworkspara facilitar a vida

muito

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

Será?

Conceito ou (infra)estrutura?

Possíveis resultados...

O que é DDD?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

Definições básicasDefiniçõ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.

Linguagem onipresenteevita desentendimentos.

Requisitos do DDDRequisitos 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

Camadas de softwaresCamadas 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

Camada de apresentaçãoCamada 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.”

Camada da aplicaçãoCamada 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.”

Camada do domínioCamada 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”

Camada de infra-estruturaCamada 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.”

Tipos dos objetosTipos dos objetos

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

Entidades

EntidadesEntidades

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.

Objetos de valor

Objetos de valorObjetos 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.

Serviços

ServiçosServiç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.

Agregados

AgregadosAgregados

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.

Fábricas

FábricasFá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).

Repositórios

RepositóriosRepositó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.

RepositóriosRepositó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

Então tudo é conceitual?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!

Cadê o PHP no meio disso tudo?

Domain Driven Design e PHPDomain 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.

PHP e OOPPHP 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).

PHP e OOPPHP 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.

Algumas ferramentas que auxiliam...

Ferramentas disponíveisFerramentas 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/

Doctrine 2Doctrine 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 Doctrine\ORM\EntityRepository que possibilita a criação de repositórios customizados (que se encaixam muito bem no conceito de Repositórios do DDD).

Symfony 2Symfony 2

Full stack framework organizado em componentes para as diversas necessidades de uma aplicação, com destaque principal nos componentes:

● Dependency Injection● HTTP Foundation

Pequeno jabá =P

ActionMapper 2ActionMapper 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

ConclusõesConclusõ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.

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

Maiores informaçõesMaiores informações

Obrigado!Obrigado!

Eu por aí: http://about.me/lcobucci

Slides: http://slideshare.net/lcobucci