PHP e Domain Driven Design: apresentando os conceitos
Linguagem ubíqua - Introdução
Boas-vindas à Alura! Meu nome é Vinicius Dias, embora vocês não estejam me vendo eu vou acompanhar vocês nesse treinamento de introdução a alguns conceitos do Domain Driven Design, ou DDD, utilizando PHP.
Primeiro nós vamos falar sobre o que é DDD, que nada mais é do que realizar o design da nossa aplicação, ou seja, modelar nossa aplicação partindo do domínio. E nós já falamos muito sobre isso nos cursos de arquitetura, no curso anterior sobre arquitetura.
Então nós vamos partir exatamente desse treinamento de arquitetura. A partir daquele treinamento nós vamos começar com essa estrutura e vamos evoluindo, onde aqui no nosso domínio nós vamos adicionar uma invariante na nossa classe de aluno, na nossa entidade, e a partir disso nós vamos entender o que é um aggregate root, nós vamos entender sobre particularidades na persistência disso.
E evoluindo, nós vamos falar um pouco sobre evento de domínio. Nós vamos entender o que são eventos de domínio e como eles podem ser úteis. Além de implementar um evento, obviamente, nós vamos aprender a publicar esse evento e a ouvir esse evento e reagir a ele.
Evoluindo um pouco nos estudos de DDD, falando sobre padrões táticos e estratégicos, nós vamos conversar um pouco sobre o que é linguagem ubíqua e outro padrão de estratégico que nós vamos conversar é sobre os contextos delimitados ou Bounded Context.
Nós vamos separar nossa aplicação em dois contextos: o contexto acadêmico e o contexto de gamificação, onde cada um deles, apesar de precisar se comunicar, não vão se conversar diretamente. Esses dois contextos vão ser independentes e vão utilizar um conceito que é chamado de shared kernel, ou núcleo compartilhado, para poder compartilhar algumas informações.
No final do treinamento, nós ainda vamos bater um papo bem rápido sobre sistemas distribuídos, embora nós não vamos implementar essa parte na prática, vai ser um papo interessante para nós entendermos como um sistema separado em contextos pode acabar evoluindo para uma arquitetura de microsserviços, ou qualquer outra arquitetura de sistemas distribuídos.
Espero que você aproveite bastante esse treinamento! É um treinamento um pouco mais denso, de um conteúdo um pouco mais avançado. Então, caso fique com dúvidas durante o treinamento não hesite, abra uma dúvida no fórum. Eu tento responder pessoalmente sempre que possível, mas quando eu não consigo, a nossa comunidade de alunos e de moderadores é muito solícita, e com certeza alguém vai conseguir te ajudar.
E lá no final, obviamente, eu vou deixar algumas referências para você se aprofundar nesse conteúdo de Domain Driven Design, arquitetura, etc.
Então vamos para o próximo vídeo para nós fazermos aquela recapitulação do curso de arquitetura e depois começar a colocar a mão na massa.
Linguagem ubíqua - Apresentação do projeto
Vamos dar só uma passada no projeto do curso anterior para todo mundo entender o que nós estamos falando.
No treinamento anterior, onde fizemos uma rápida introdução sobre o que é que uma arquitetura de software e nós montamos uma arquitetura para nossa aplicação, inclusive com alguns testes. Nós vimos um projeto onde nós teríamos alunos, esses alunos poderiam indicar outros alunos, etc.
Alguns desafios foram deixados, para que vocês fossem fazendo durante o treinamento, mas aqui eu só vou mostrar os arquivos que foram feitos durante o treinamento junto comigo. Então aqui na nossa aplicação nós temos o use case, nós temos aquele application service.
Ou aquele nosso caso de uso, de matricular um aluno e para matricular aluno nós precisamos dos dados dele, do CPF, nome e e-mail. E com isso, nós realizamos o fluxo da nossa aplicação, onde nós criávamos esse aluno, adicionava esse aluno no repositório, etc.
Nós temos a parte de indicação, onde nós começamos a criar uma Interface para enviar e-mail de indicação quando aluno fosse indicado, etc. No nosso domínio, nós temos tudo referente ao aluno, seja a sua entidade, os value objects relacionados à ele, as exceções caso existissem algumas, algumas interfaces. E relacionado a indicação, nós não entramos muito nesses detalhes então nós só temos uma entidade.
E aqui nós tomos os value objects que são genéricos no nosso domínio da aplicação, que podem ser utilizados tanto na indicação, quanto no aluno, ou em qualquer outro módulo que nós viéssemos a desenvolver por aqui.
Então com isso, nós temos o nosso domínio e para implementação de algumas partes do domínio nós temos em infraestrutura, onde nós cuidamos de criptografia de senha, cuidamos de repositório, etc. Inclusive com esse repositório em memória, nós vimos que ia ser mais fácil criar alguns testes, etc.
Com esse projeto já em mente, vamos começar a falar um pouco, a bater um papo sobre o que é Domain Driven Design, ou seja, desenvolvimento guiado a domínio. E essa palavra domínio, já está escrito aqui na nossa arquitetura, nós já começamos a montar nosso sistema pensando nela.
E se nós já começamos a pensar no nosso domínio, se o domínio já faz parte da nossa aplicação, já faz parte do nosso sistema, enquanto nós desenvolvemos no curso anterior, talvez nós já tenhamos feito algumas coisas, talvez nós já tenhamos implementado algumas técnicas que o estudo de DDD, o Domain Driven Design, ou o desenvolvimento guiado a domínio, talvez nós já tenhamos implementado algumas coisas sugeridas nessa literatura.
Então no próximo vídeo, nós vamos ver exatamente isso, o que do nosso projeto já está em conformidade aos estudos de DDD. Então o que nós fizemos até aqui que já fazem parte do estudo de “DDD”. Então no próximo vídeo nós batemos esse papo
Linguagem ubíqua - O que já aprendemos
No treinamento anterior, nós trabalhamos bastante com essa imagem.
Essa imagem foi mostrada mais de uma vez, e essa imagem é uma imagem tirada do livro que originou o estudo do DDD e nessa imagem nós já começamos a pegar alguns detalhes, nós já começamos a pegar alguns insights para aplicar no nosso sistema.
Então se você reparar, nós temos três camadas da nossa arquitetura: aplicação, domínio e infraestrutura. E essas três camadas são sugeridas pelo DDD.
Na sugestão que é feita no livro do DDD existem algumas diferenças, por exemplo, no livro do DDD é sugerido que o domínio possa utilizar alguns detalhes de infraestrutura, da mesma forma que aplicação pode utilizar alguns detalhes de infraestrutura.
Mas nós vimos no nosso estudo de arquitetura que é interessante isolar o domínio da infraestrutura, de forma que ele nunca dependa de nada diretamente. Então nós fizemos aquela inversão de dependência, criando as nossas interfaces. Tanto para cifrar senha, quanto para tratar repositório de alunos.
Mas o conceito da arquitetura nós já começamos a fazer utilizando conceitos do DDD. Então essa arquitetura separada em camadas, onde o domínio é uma camada separada, é algo independente, faz parte do estudo de DDD.
Então antes de tudo, é importante ressaltar, eu já falei no vídeo anterior, mas que DDD significa domain driven design, ou seja, design, modelagem orientado a domínio, ou seja, o mais importante na nossa aplicação é o domínio. Nós pensamos no domínio, e a partir do domínio nós desenvolvemos nossa aplicação, adiciona detalhes de infraestrutura, etc.
E uma coisa que nós não fizemos na nossa aplicação, não fizemos no nosso sistema, foi essa camada de interface com o usuário. Eu deixei como desafio para que vocês pensassem nessa camada. E nesse treinamento nós também não vamos tratar ela, porque essa camada pode ser implementada de inúmeras formas, nós lá no final do treinamento vamos falar um pouquinho sobre as possibilidades. Mas de novo, isso vai ser um desafio para vocês tentarem.
Mas voltando para a parte que nós já estudamos e vamos nos aprofundar mais, sobre o DDD, nós vimos a necessidade de cada uma dessas camadas e para implementar detalhes de cada uma dessas camadas, nós já vimos conceitos que a literatura do DDD ensina para nós. Então vamos dar uma passada bem rápida sobre o que nós já vimos.
Nós começamos falando sobre entidades, que são classes no nosso sistema que vão gerar objetos com identidade, e no nosso caso a gente utilizou CPF como identidade. Então o conceito de entidade é um estudo muito focado do DDD. Nos livros de DDD existem capítulos específicos sobre entidade tratando sobre esses detalhes.
Por exemplo, eu comentei no curso anterior que nós iriámos utilizar CPF como chave primária, vamos dizer assim, como identificador único de cada um dos alunos. Eu poderia utilizar um ID, por exemplo, um private int $id, eu poderia fazer isso e fazer com que o banco de dados gerasse o meu ID.
Só que isso, segundo os estudos de domain driven design, está ferindo o meu domínio. Porque um domínio para, por exemplo, um especialista de negócios, um aluno não tem um ID, ele tem um CPF, ele sabe identificar um aluno por um CPF. Então nós trazemos esses detalhes do domínio, da nossa realidade do negócio, para nossa aplicação. E foi exatamente isso que nós fizemos.
Então sempre que nós pudermos blindar o nosso domínio de qualquer detalhe de infraestrutura, nós vamos preferir essa abordagem. Lembrando, que toda escolha, toda abordagem no mundo do desenvolvimento têm prós e contras. Aqui nós temos a vantagem de não depender de um banco de dados relacional que gere o ID automaticamente para nós, então existe essa vantagem.
Mas a desvantagem é que nós temos que tratar a validação de CPF, esse tipo de detalhe. Então tudo é um trade-off, ou seja, é uma escolha. Nós precisamos pesar as vantagens e desvantagens.
Mas beleza, voltando ao assunto de DDD, nós falamos sobre entidade e diretamente relacionados a entidades nós temos os value objects. Value objects são muito semelhantes a entidades, uma diferença de que eles não possuem uma identidade, o que quer dizer, um telefone que tem esse o número e seu DDD iguais, é um telefone igual. Então se eu tenho dois telefones com DDD 24 e o número 22222222, esses dois telefones são iguais, são o mesmo telefone.
Então esse conceito de igualdade e identidade é o que divide, é o que diferencia entidades de value objects. Então nós já tratamos bastante sobre isso, já conversamos sobre isso, e avançando um pouco mais a gente falou sobre repositórios. Repositórios também é um conceito citado em DDD. Repositório faz parte do nosso domínio. Toda, ou pelo menos a maioria dos sistemas possuem algum repositório, uma forma de persistir as entidades, de persistir value objects.
E esse repositório, embora faça parte do domínio, depende de alguma infraestrutura. Então por nós vimos que deveríamos definir a linha 7 como uma interface, e lá na infraestrutura nós implementaríamos os detalhes, seja utilizando SQL, seja utilizando um banco no SQL, seja utilizando memória, arquivo, o que for. Então nós já vimos mais um conceito, que é o de repositórios.
E um conceito um pouco mais complexo, mas que nós temos tratado sem tanta ênfase, desde lá dos nossos cursos de “Orientação objetos”, é o conceito de serviços. Os services são classes que realizam alguma tarefa que não faz parte de nenhuma entidade, porque nossa regra de negócios reside nas entidades como, por exemplo, eu sei como eu adiciono um telefone, eu sei as regras do meu CPF, então nas entidades e nos value objects eu tenho as regras de negócio.
Só que se eu possuo alguma regra na minha aplicação ou no meu domínio que não faça parte de nenhuma entidade, eu preciso separar isso em uma classe específica, como é o caso de realizar criptografia de senha. Eu sei que faz parte do meu negócio, eu preciso criptografar a senha dos alunos, só que isso, de novo, depende de detalhes de infraestrutura. Então nós separamos em um serviço de infraestrutura.
Então nós temos domain services, que são serviços que organizam regras de várias entidades. Nós temos infrastructure services, ou seja, serviços de infraestrutura, que são serviços, são regras que dependem de algum detalhe de infraestrutura. E nós vimos, o mais complexo e mais polêmico, que são os application services, ou serviços de aplicação, que são os casos de uso, que são o que nós fazemos para organizar o fluxo da aplicação.
Por exemplo, em uma aplicação web, você pode entender que um controller é uma espécie de application service. Ele pega a requisição, os dados que vem da requisição, e realiza o fluxo da sua aplicação, chamando as classes necessárias. Só que nesse código nós fomos um passo além e criamos uma classe específica, que não depende da web, e para receber os dados sem depender da web, nós criamos o DTO, ou seja, data transfer object.
Isso tudo fez parte da nossa arquitetura, isso tudo tem relação a como separar a nossa aplicação do nosso domínio, da infraestrutura, da web em si. Então vários conceitos aqui, que nós já vimos sobre DDD.
Então recapitulando, nós vimos entidades, nós vimos value objects, repositories, nós vimos services, nós falamos sobre factory. Então nós vimos bastante coisa. E isso tudo, todos esses conceitos práticos que nós vimos são chamados dos padrões táticos no DDD, e o DDD é separado em padrões táticos que são essa parte mais prática e os padrões estratégicos.
Os padrões estratégicos falam mais sobre como nós nos comunicamos entre a equipe de desenvolvimento e a equipe de negócios, mais relacionada à parte de negócios. Então nós vamos falar sobre o padrão estratégico mais conhecido e mais falado do DDD só que no próximo vídeo.
Sobre o curso PHP e Domain Driven Design: apresentando os conceitos
O curso PHP e Domain Driven Design: apresentando os conceitos possui 123 minutos de vídeos, em um total de 49 atividades. Gostou? Conheça nossos outros cursos de PHP em Programação, ou leia nossos artigos de Programação.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
- Linguagem ubíqua
- Sobre aggregates
- Evento de domínio
- Contextos delimitados
- Contexto compartilhado
- Camada anticorrupção
