View
689
Download
2
Category
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
Recommended