Arquitetura Java: modelando aplicações com Domain-Driven Design
Conhecendo o projeto CodeChella - Apresentação
Olá, tudo bem? Sou a Jacqueline Oliveira, engenheira de software e instrutora aqui na Alura. Para fins de acessibilidade, vou me autodescrever.
Audiodescrição: Jacqueline é uma mulher de pele branca, com cabelos loiros e longos. Veste uma blusa verde e está nos estúdios da Alura. Ao fundo, há uma iluminação azul e verde e uma prateleira à direita com alguns objetos.
O que vamos aprender?
A proposta deste curso é apresentar para você os conceitos do Domain Driven Design (Desenvolvimento Orientado ao Domínio), para que você possa criar aplicações que sejam realmente relevantes para o negócio, para o cliente.
O Domain Driven Design é o desenvolvimento orientado ao domínio.
Toda a nossa modelagem, todos os conceitos que serão apresentados, são para que você consiga entender o real problema que precisa resolver na aplicação. E não simplesmente fazer um CRUD ou criar uma aplicação que grava dados em um banco de dados.
Com o Domain Driven Design, você é capaz de criar uma aplicação que é realmente relevante, que resolve o que é necessário. Para apresentar para você esses conceitos, vamos utilizar o nosso projeto fictício CodeChella, cujo objetivo é administrar a venda de ingressos para eventos.
- Identificar as regras de negócio;
- Linguagem ubíqua;
- Modelagem da aplicação;
- Design estratégico e tático.
Com isso, vamos identificar quais são as regras de negócio, como deve funcionar essa venda de ingressos, qual tipo de linguagem que temos que usar, o nosso especialista de negócio, que linguagem ele entende quando está falando da venda de ingressos, é ingresso, é ticket? Como vamos modelar a aplicação? Vamos abordar sobre design estratégico e tático.
Esse conteúdo será muito importante para você que está avançando com Java, Spring e arquitetura de código.
Pré-requisitos
Inclusive, esse curso é indicado para você que já fez o curso de Clean Architecture, então já conhece alguns aspectos de arquitetura de software e vai aprimorar os seus conhecimentos aqui, trabalhando com design diferenciado, orientado ao domínio.
Estou animada para passar esse conhecimento para você e espero você logo em seguida!
Conhecendo o projeto CodeChella - Entendendo o projeto
Iniciaremos nossos estudos abordando sobre o projeto que será abordado ao longo do curso. Trabalharemos com o CodeChella, o mesmo projeto que utilizamos no curso de Clean Architecture (Arquitetura Limpa), que é um site para venda de ingressos para diversos eventos.
No entanto, no curso de Clean Architecture, trabalhamos com um escopo reduzido, focado apenas em usuários. Neste curso, trabalharemos com a aplicação completa.
Se analisarmos no IntelliJ, veremos que temos inúmeras classes. Analisaremos no diagrama de classes para entender o fluxo dessa aplicação.
Analisando o fluxo da aplicação
No diagrama de classes, podemos verificar que teremos cinco tabelas em nosso banco de dados.
A tabela de eventos, onde um evento terá vários tipos de ingressos, seja pista, camarote ou cadeira, cada um com suas respectivas informações.
Temos a tabela de usuários e a tabela de vendas, que vai vincular um tipo de usuário que fará a venda e os ingressos que essa pessoa está comprando pelo tipo e código.
Para saber como fazer os inserts no banco, teremos três endpoints. Vamos abrir o Postman e verificar como faremos.
Usando o Postman
O primeiro endpoint é de usuários (http://localhost:8081/usuarios), o mesmo que trabalhamos no curso de Clean Architecture. Faremos um post para usuários, cadastrando a usuária Jaqueline. Para isso, clicamos no botão azul "Send" do lado superior direito.
{
"cpf": "123.456.789-00",
"nome": "Jacqueline Oliveira",
"nascimento": "1980-09-08",
"email": "jacqueline.oliveira@alura.com.br"
}
Deixarei essa documentação no formato JSON para que você também possa fazer o cadastro.
Em "Pretty" na parte inferior, obtemos:
{
"id": 1,
"cpf": "123.456.789-00",
"nome": "Jacqueline Oliveira",
"nascimento": "1980-09-08",
"email": "jacqueline.oliveira@alura.com.br"
}
Na segunda aba (http://localhost:8081/eventos), temos um exemplo de um evento, categoria música, show da Taylor Swift, os tipos de ingressos, pista, pista premium, quais os valores, o total disponível.
{
"categoria": "MÚSICA",
"descricao": "Taylors Swift - The Eras Tour",
"endereco": {"cep": "20756970", "numero": "578", "complemento": "Engenho de Dentro"},
"data": "2025-11-19T19:00:00",
"tipoIngressos": [
{"formato": "PISTA", "definicao": "INTEIRA", "valor": 850.85, "totalDisponivel": 10000},
{"formato": "PISTA_PREMIUM", "definicao": "INTEIRA", "valor": 1200, "totalDisponivel": 5000},
{"formato": "CADEIRA", "definicao": "INTEIRA", "valor": 600, "totalDisponivel": 10000},
{"formato": "CADEIRA", "definicao": "MEIA", "valor": 320, "totalDisponivel": 10000}
]
}
Faremos um post para o endpoint de eventos clicando em "Send". Ele já criou para nós.
Neste momento do vídeo a instrutora altera o campo "data" do evento para 2025. A data já está ajustada na transcrição.
Em "Pretty" na parte inferior, ela obtém o seguinte retorno ao enviar a data com "2023":
[
{
"campo": "data",
"mensagem": "Data do evento deve ser uma data futura!"
}
]
Ele já possui validações, então está informando que a data do evento deve ser uma data futura.
Continuando, cadastrou o show da Taylor para o ano de 2025, os tipos de ingressos. Observamos isso na parte inferior em "Pretty".
Agora faremos uma venda simulando esses tipos de ingressos clicando na próxima aba.
http://localhost:8081/vendas
Faremos um post para o endpoint de vendas, também deixaremos esse JSON para que você possa simular e tentar reproduzir seus cadastros.
{
"usuario_id": 1,
"ingressos": [
{"codigo": 125, "tipo_id": 3},
{"codigo": 126, "tipo_id": 1}
]
}
Clicamos em "Send" e ele já cadastrou uma venda para a usuária 1 e os tipos de ingresso que essa pessoa comprou. Então, Jaqueline comprou um ingresso para cadeira na definição inteira, o código 125 e um 126 que é a pista.
Nossa aplicação já está pronta, temos nossa API, nossos endpoints, vimos o diagrama de classe. Mas repare, todo esse código está orientado à CRUD ou orientado à persistência, e isso é muito comum acontecer, e não é de hoje.
Mais ou menos entre 1990 e os anos 2000, a forma de se fazer software era justamente essa. Perguntávamos para o cliente, que tipo de relatório você precisa gerar? Ele respondia, e na mesma hora já pensávamos na tabela, para gerar esse relatório, preciso cadastrar isso e o modelo de tabelas vai ser assim e o banco daquele outro jeito.
Era direcionado à persistência, como eu ia persistir, como eu ia exibir relatórios, e hoje em dia vemos um grande movimento para dizer que tudo é CRUD.
No entanto, essa abordagem não atende quando pensamos no negócio. Qual é o nosso negócio? O que o CodeChella precisa fazer? Quais são as regras do nosso negócio?
Para colocar um evento, quantos ingressos estarão disponíveis? O que vai acontecer se várias pessoas tentarem comprar ao mesmo tempo? Podemos deixar uma pessoa comprar 50 ingressos ao mesmo tempo, precisamos limitar? Essas regras de como o domínio deve funcionar passaram despercebidas, não estão implementadas no projeto.
E essa é uma das abordagens que utilizamos quando usamos o DDD, que é o Domain Driven Design (Design Orientado ao Domínio). Pensamos na forma de desenvolver software analisando os problemas do negócio. O que o negócio precisa? Quais são os requisitos desse negócio? O que o negócio precisa entregar? O que preciso resolver ou implementar no software para atender esse negócio?
Exatamente essa é a ideia do Domain Driven Design:orientamos a nossa construção de código a partir do que o negócio precisa.
Conclusão e Próximos Passos
Neste curso, você pode observar que trabalharemos com muito menos código do que no curso de Clean Architecture, onde fomos construindo a arquitetura passo a passo.
Aqui, a nossa ideia é ter uma mudança de mentalidade para, em vez de olhar a persistência, o endpoint, o controller, qual tipo de banco de dados, vamos pensar no negócio. O que o negócio precisa? O que precisamos resolver? Como vamos fazer um software funcional que atenda às necessidades que o cliente precisa?
Esse é o nosso foco aqui. Espero que você esteja animado. Vamos praticar, vamos pensar, vamos conversar bastante e descobrir e abordar um pouco mais sobre o que é esse Domain Driven Design.
Conhecendo o projeto CodeChella - Desvendando a complexidade do software
O conceito de Domain Driven Design (Design Orientado ao Domínio) foi abordado pela primeira vez em 2003, no livro de Eric Evans. Ele tem uma frase bem categórica: "Atacando a complexidade no coração do software". Quando estamos desenvolvendo uma aplicação, temos basicamente dois tipos de complexidade.
Tipos de complexidades
A complexidade que chamamos de acidental, que são as dívidas técnicas que adquirimos ao longo do tempo, a dificuldade de implementar coisas no código legado, a dificuldade de infraestrutura, frameworks, banco de dados. Isso é uma complexidade acidental.
Mas o ideal é atacarmos a complexidade essencial. Qual é a complexidade essencial? É a complexidade de negócio, porque é o motivo real pelo qual alguém vai pagar a você, pessoa desenvolvedora, ou a uma empresa, para desenvolver o software para ela. Ela quer resolver, ela quer ter o fluxo dela resolvido, o negócio dela ali, da maneira que ela precisa.
Quando você conversa com um especialista de negócio, ele não quer saber se você vai fazer o front-end com React, com Vue, qual banco de dados você vai usar naquele momento.
Não é isso que a pessoa quer saber, ela quer saber como você vai resolver para que ela cadastre um evento, que ela faça a venda de ingressos, que ela consiga ter simultaneamente várias pessoas fazendo a compra. Assim, as complexidades de negócio, essas sim, são as que precisam ser atacadas.
Logo depois desse livro, houve algumas outras publicações como o Implementing Domain-Driven Design, do Vaughn Vernon de 2013, 10 anos depois. Posteriormente, em 2016, tivemos o lançamento desse terceiro livro, que é o Domain Driven Design Distilled.
Livros
- Domain-Driven Design, Eric Evans.
- Implementing Domain-Driven Design, Vaughn Vernon.
- Domain-Driven Design Distilled,Vaughn Vernon.
Vale a pena a leitura, não são leituras simples de se fazerem, mas são leituras extremamente relevantes para que você consiga desenvolver aplicações que atendam, de fato, ao que o negócio precisa.
Entendendo a complexidade do software
Por que precisamos atacar complexidades do software? Por que não vamos mostrar neste curso tanto a parte de código? Porque não existe você procurar no Google, por exemplo: "como implementar um projeto de venda de ingressos com DDD". Isso não existe, porque cada empresa, cada contexto vai ser diferente.
O CodeChella vai funcionar de uma forma, outras empresas que vendem ingresso vão ter outras nomenclaturas, outros fluxos, outras formas de trabalhar, outras parcerias. Vai estar estruturado diferente.
Se o nosso desenvolvimento precisa ser orientado ao domínio, precisamos ser específicos. Não tem uma receita de bolo para criar uma aplicação usando o DDD que vá atender a todos os casos de empresas que têm a mesma regra de trabalho.
Por exemplo, duas empresas de streaming, a Netflix e a Prime Video. Cada uma delas trabalha de um jeito diferente. Apesar de ter o mesmo objetivo, que é fazer streaming de vídeos, cada uma vai ter uma forma de funcionar. Então, não podemos fazer um projeto DDD que vá atender as duas.
Temos que estar claro que isso realmente é uma virada de chave, de mindset (mentalidade), a palavra em inglês que é muito usada hoje em dia. O DDD é justamente isso, é você mudar o mindset para tentar atacar o que é complexidade de negócio.
Complexidade no projeto CodeChella
Falando sobre complexidade, podemos considerar rapidamente algumas complexidades observadas aqui no CodeChella.
Por exemplo, imagine que existem diferentes setores. Um desses setores é o de vendas, responsável por prospectar quem será o público-alvo do evento: crianças, adolescentes ou jovens? Assim, no contexto de vendas, o cliente é referido como "prospect" ou "lead" por eles.
O cliente para o setor de vendas, ele é um prospect. Já quando estamos falando de customer success, a pessoa que já comprou o ingresso, já sabe o evento que vai e está tendo algum problema, para o customer success, essa pessoa se chama usuário.
Então, temos outra complexidade, estamos pensando em outra coisa, usando outra linguagem. Para o financeiro, também vamos ter outro tipo de abordagem. O cliente é chamado de cliente e o evento que ele comprou, chamamos de evento.
Para o B2B, que faz parcerias, queremos fazer um evento e desejamos chamar empresas que vão trabalhar nesse evento, fornecendo comida e brindes. Assim, o cliente do B2B vai ser um parceiro e o que ele vai vender é um produto.
Repara que , para o CodeChella, cada setor trata cliente de uma forma, um chama de prospect, outro de usuário, outro de cliente, outro de parceiro.
Cada setor tem sua própria terminologia para o que estão vendendo - seja produto, ingresso ou evento.
Conclusão e Próximos Passos
Com isso, compreender como tudo isso funciona e como podemos incorporar isso na aplicação torna-se complexo.
É por isso que o Domain-Driven Design (DDD) possui pilares que auxiliam nesse processo, focando no entendimento do domínio do negócio. Mais adiante, iremos explorar detalhadamente esses pilares e como podemos modelar a aplicação da melhor forma possível para atender às necessidades do especialista de negócios e da empresa contratante.
Sobre o curso Arquitetura Java: modelando aplicações com Domain-Driven Design
O curso Arquitetura Java: modelando aplicações com Domain-Driven Design possui 126 minutos de vídeos, em um total de 47 atividades. Gostou? Conheça nossos outros cursos de Java 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:
- Conhecendo o projeto CodeChella
- Atuando no Design Estratégico
- Partindo para o Design Tático
- Contexto compartilhado e camada anticorrupção
- Consolidando conhecimentos
