Domain-Driven Design

Projeto Orientado a Domínio com PHP

Paulo Victor L. L. Gomespv.gome89@gmail.comwww.profpv.comwww.profpv.com/blog

github.com/pvgomesgithub.com/profpvbitbucket.org/profpv

Licenciamento desta apresentação

BY - NC - SACompartilhe - Mantenha a licença - Não comercial

http://creativecommons.org/licenses/by-nc-sa/3.0/

Domain-Driven Design?Domain-Driven Design é uma abordagem para o Desenvolvimento de Software que estabelece uma forte ligação entre a implementação e o modelo evolutivo dos conceitos de negócio. Implementação X Negócios

Não é uma tecnologia ou uma metodologia. DDD fornece uma estrutura de práticas e terminologia para a tomada de decisões de design. O foco é acelerar os projetos de software e alinhar com os domínios de negócio.

Não faz sentidoOnde eu coloco a minha regra de negócio?

Resposta desse cara ao lado no contexto em que ele se encontra: “Na camada de apresentação, no banco de dados nos controles, modelos, na configuração do webserver e não esquece do xml”

Encapsulamento...Encapsule a regra de negócio! Fazendo isso, garantimos consistência e simplicidade.

Orientação a Objetos?

Orientação a ObjetosMeu framework já usa Orientação a Objetos. Esse papo é muito antigo e eu já superei esse problema.

Orientação a ObjetosOlhem meus métodos:

Orientação a ObjetosQuando pensamos em POO logo pensamos em Classes, Encapsulamento, Polimorfismo, Herança...

POO é mais que isso, a essência da POO é alinhamento do código com o negócio, reutilização, mínimo de acoplamento, linguagem natural...

DDD na práticaColocando o modelo de domínio para funcionar.

Para que um software atenda um domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua(Linguagem comum, com termos bem definidos, que fazem parte do domínio do negócio e que são usados por todas as pessoas que fazem parte do processo de desenvolvimento de software)

“Temos que emitir a fatura para o cliente antes da data limite”

Uma classe para a entidade Cliente;Uma classe para a entidade Fatura;Algum serviço que tenha um método emitir;Algum atributo com o nome de data limite.

Essa linguagem ubíqua deve ser compreendida por todos e não pode haver ambiguidades.

Linguagem UbíquaDefinições de Ubíqua

“O termo foi usado pela primeira vez pelo cientista Norte-Americano Mark Weiser em 1988 e publicado em 1991 no seu artigo The Computer for the 21st Century”

“termo usado para descrever a onipresença da informática no cotidiano das pessoas”

“Computação ubíqua tem como objetivo tornar a interação homem computador invisível, ou seja, integrar a informática com as ações e comportamentos naturais das pessoas”

Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A ideia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio.

MDD – Model Driven Design

O MDD defende o processo ágil, o trabalho em equipe ou seja, especialistas em negócio, desenvolvedores e arquitetos trabalhando juntos.

Diagramas da UML ajudam o entedimento do domínio.

Encapsulando o modelo de domínio.

Blocos de ConstruçãoInterface de Usuário – Interação com o 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 compreenderprofundamente 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, etc.

Entidades

Muitos objetos não são fundamentalmente definidos por seus atributos, mas sim por uma linha de continuidade e identidade

Objetos de valor

Muitos objetos não possuem nenhuma identidade conceitual. Esses objetos descrevem alguma característica de alguma coisa.

Serviços

Ás vezes, a situação simplesmente não se trata de alguma coisa. Em algums casos, um design mais limpo e mais pragmático inclui operações que não pertencem conceitualmente a nenhum objeto. Em vez de forçar a questão, podemos seguir os limites naturais do espaço do problema e incluir SERVIÇOS explicitamente no modelo.

Agregados

O design detalhado de associações ajuda a simplificar um comportamento de um objeto mas, em diversos casos, existe a necessidade de explorar a modelagem se adequando com o domínio complexo.

Fábricas

Quando a criação de um objeto ou um AGREGADO inteiro se torna complicada ou revela uma grande parte de estrutura interna, as FÁBRICAS fornecem o encapsulamento.

Repositórios

Associações nos permitem achar um objeto baseado em sua relação com outro objeto. Mas é preciso ter um ponto de partida para uma travessia até uma ENTIDADE ou um VALOR no meio do seu ciclo de vida.

Tijolos de construção

Plataforma EducacionalMagiZ, a Plataforma Educacional Online completa, configurável e fácil de usar.www.magiz.com.br

Tecnologias utilizadas

Arquitetura base

DDD no ZF2

https://github.com/pvgomes/dddzf2

Perguntas?

ReferênciaTudo sobre DDDhttp://dddcommunity.org/

Mini-book de DDDhttp://www.infoq.com/minibooks/domain-driven-design-quickly

Domain Driven Designhttp://domaindrivendesign.org/

Vídeo de Introdução a DDDhttp://vimeo.com/3545313

Vídeos sobre Projeto Estratégiohttp://vimeo.com/3972348

http://www.infoq.com/presentations/strategic-design-evans

Vídeo Colocando o Modelo para Funcionarhttp://www.infoq.com/presentations/model-to-work-evans