Entre para a LISTA VIP da Black Friday

00

DIAS

00

HORAS

00

MIN

00

SEG

Clique para saber mais
Alura > Cursos de Programação > Cursos de Java > Conteúdos de Java > Primeiras aulas do curso Arquitetura Java: descomplicando a Clean Architecture

Arquitetura Java: descomplicando a Clean Architecture

Conhecendo o projeto CodeChella - Apresentação

Olá! 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 longos e loiros. Veste uma blusa verde lisa e está nos estúdios da Alura. Ao fundo, há uma iluminação azul e verde.

O que vamos aprender?

Neste curso, vamos trabalhar desvendando a Clean Architecture (Arquitetura Limpa). É um tipo de arquitetura muito utilizada para prever modificações futuras em um projeto. Se houver mudança de framework, de banco de dados, de tecnologia, a Clean Architecture ajuda a mapear e traçar caminhos para deixar o seu produto mais manutenível. E é isso que vamos desvendar aqui.

Para fazer isso, vamos usar um projeto chamado CodeChella, que é um site para venda de ingressos, ingressos de eventos distintos. Vamos trabalhar neste curso em um escopo de usuários.

Vamos começar com uma aplicação MVC que inclui uma API Rest para o cadastro e listagem de pessoas usuárias, algo que é comum na programação utilizando Spring e Java. A proposta é migrar essa estrutura MVC para uma arquitetura Clean que segue os princípios definidos por Uncle Bob na Clean Architecture.

Para quem é este conteúdo?

Este conteúdo é para você que já tem conhecimento em orientação a objetos e Spring. Portanto, é muito importante que você tenha feito a formação anterior de Spring, de orientação a objetos, porque neste curso vamos partir do princípio que você conhece esses temas.

Então, vamos lá! Pegue a sua água, pegue o seu café, venha com disposição, que tem muita coisa para nós aprendermos. Espero você no próximo vídeo!

Conhecendo o projeto CodeChella - O que é Arquitetura?

Antes de mergulharmos efetivamente no assunto Clean Architecture (Arquitetura Limpa), que é o foco do nosso curso, é importante trazermos o questionamento: o que é arquitetura de software? Normalmente, quando ouvimos a palavra arquitetura, associamos à profissão de arquiteto.

O que essa pessoa faz? Quando temos um terreno e desejamos construir uma casa, chamamos esse profissional que vai fazer o desenho de como será a casa, qual o tamanho da sala, do quarto, onde vai passar o encanamento, a parte elétrica. Portanto, é uma pessoa que pensa em tudo e desenha como tudo vai se conectar.

Na parte de software, não é diferente. Uma pessoa arquiteta é quem vai pensar como a nossa aplicação vai se conectar com o banco de dados, com a interface gráfica e como vai acontecer o deploy.

Atualmente, temos muitas aplicações onde se fala que é tudo CRUD (Create, Read, Update, Delete). Então, tem essa falsa sensação de que a arquitetura é só dividir em três pastas: Domain, Infra e Application. Mas não, a arquitetura é muito mais do que isso.

Vamos analisar o projeto que vamos trabalhar neste curso, para verificar como vamos pensar na arquitetura dele.

Analisando o projeto

O projeto que vamos trabalhar é o CodeChella. O CodeChella é um site que tem alguns eventos cadastrados para que as pessoas clientes comprem os ingressos. O site possui algumas atrações, é um site fictício. System of a Dom, Python Maiden, então tem um lado nerd divertido que colocamos.

Mas a ideia é essa, com certeza você já comprou ingresso para algum evento em um site desses e sabe que tem várias etapas ali, tem a interface gráfica, tem o cadastro. E a pessoa arquiteta tem que pensar nisso tudo, como será a interface, qual será o banco de dados. E se tivermos muitas solicitações para um evento muito grande, como vamos tratar isso.

Na parte superior direita do site, temos uma página, tem a seção do ingresso, de setores, a parte de usuários. E esse é o nosso projeto fictício, que vamos tratar aqui e pensar na arquitetura dele.

Por que atualmente existe tanta preocupação com arquitetura?

Entre os anos 90 e 2000, mais ou menos, a maioria das aplicações eram aplicações desktop. As pessoas não tinham acesso à internet, aquele "boom" da internet ainda não tinha acontecido.

Quando ela de fato aconteceu e passamos a ter aplicações web e posteriormente aplicações mobile, foi percebida uma dificuldade para pegar as aplicações existentes e modificar. Muitas vezes as aplicações tinham que ser completamente reescritas para essa nova realidade.

Arquitetura Ports & Adapters Pattern

Portanto, foram surgindo algumas propostas de arquiteturas que vou citar rapidamente e vamos falando mais ao longo do curso, vou deixar material extra também. Uma das primeiras que surgiu foi a ideia de arquitetura hexagonal, por Alistair Cockburn.

Diagrama de arquitetura de software ilustrando a estrutura de entrada e saída de dados. À esquerda, três fontes de dados: 'Interface Web', 'Interface Mobile' e 'Sistema Externo', conectadas por linhas etiquetadas 'REST', 'GraphQL' e 'gRPC', respectivamente, a um componente central chamado 'Adaptador'. À direita, esse adaptador se conecta a um hexágono grande rotulado internamente com 'Porta Entrada', seguido por 'Classes Domínio' e 'Porta Saída', em um fluxo top-down. Da 'Porta Saída', outra linha etiquetada 'SQL' conecta a um retângulo à direita rotulado 'Banco Dados'. O esquema apresenta uma paleta de cores verde e preto, com um fundo escuro e linhas e texto em tonalidades de verde.

Mais ou menos em 2005 ele publicou, ela está representada na imagem acima. Qual é a ideia? Isolarmos o domínio da aplicação e todas as interferências externas acontecerem através de portas e adaptadores. Essa arquitetura também é conhecida como ports & adapters.

Não importa se estamos lidando com uma interface web ou mobile, ambas enviarão mensagens para um adaptador, que por sua vez encaminhará para uma porta, permitindo que a mensagem chegue à nossa aplicação. Da mesma forma, a mensagem de saída passará por esse mesmo processo.

Esse método nos permite isolar nosso domínio. E por que fazemos isso? Para garantir que se precisarmos fazer alguma modificação, aquela parte específica esteja claramente definida, bem isolada e seja facilmente adaptável a qualquer mudança futura.

Arquitetura Onion Architecture

Logo depois, também surgiu uma nova proposta que foi pelo Jeffrey Palermo, em 2008, que foi a Onion Architecture (Arquitetura em Cebola). Ele propõe essa ideia da arquitetura em cebola.

Diagrama circular concêntrico em tons de verde, representando camadas de uma arquitetura de software. No centro, a camada mais interna intitula-se "Entidades de Domínio". Em torno dela, a segunda camada é denominada "Interface Repository". A terceira camada é rotulada como "Interface Service". A quarta camada possui: "Infraestrutura", "WCF", "UI - Interface de Usuário" e "Testes de unidade". Setas partem das camadas externas apontando para as internas.

Por quê? Porque o núcleo que vai ser o nosso domínio, ele está ali no meio, ele é o núcleo e as camadas externas a ele, elas vão se conhecendo, porém nunca de dentro para fora. Isso é uma relação unidirecional.

A camada externa vai conhecendo a de dentro, que vai conhecendo a de dentro e é assim que conseguimos fazer mais proteção. Porque se o nosso domínio não conhece nada de infra, significa que ele está isolado e é possível de ser testado e modificado, independente desses fatores externos.

Clean Architecture

E a Clean Architecture, que é o que vamos trabalhar neste curso, ela é uma evolução dessas todas, é uma mistura de um pouquinho desses conceitos. Ela foi escrita pelo Uncle Bob, em 2012, e ela tem também várias camadas parecidas com a Onion Architecture, também de forma unidirecional.

Diagrama circular representando a arquitetura de software em camadas concêntricas, com a parte mais interna rotulada como "Entidades", cercada por "Casos de Uso", seguida pelos "Controladores" e na mesma camada "Gateway" e "Apresentadores", e na camada mais externa temos "UI", "Banco de Dados", "Framework", "Dispositivos" e "Web". Do lado direito, setas apontam para dentro do círculo. No canto superior direito temos "Regra de negócio da empresa" que aponta para a camada "Entidades"; "Regras de negócio da aplicação" que aponta para a camada "Casos de Uso"; "Adaptadores de interface" que aponta para "Gateway", "Apresentadores" e "Controladores"; por fim, "Framework e drivers" que aponta para a camada "Web", "Dispositivos", "Banco de Dados", "Framework" e "Ui".

O domínio nunca conhece as camadas de fora, ele tem que ser completamente independente de infra, de banco, de framework.

Então, essa é a ideia que vamos ver aqui, de ter essa independência, ter uma aplicação. Por exemplo, uma aplicação Java, que se resolvermos trocar o framework, não desejamos mais trabalhar com Spring, todas as nossas classes, o nosso domínio, a nossa regra de negócio, ela está ali intacta, ela é só código Java. Então, não tem acoplamento.

A grande ideia dessas propostas de arquitetura são justamente essas. Deixaremos esse link do site do Uncle Bob, do Clean Coder. A ideia é que ele tem cinco grandes ideias quando ele propõe arquitetura.

A primeira é ser independente de framework, podermos trocar o framework a hora que quisermos. Ser altamente testável, conseguirmos testar regras do nosso domínio sem ter que subir aplicação e banco e várias outras coisas para que possamos fazer isso.

Ser independente de interface gráfica, não importa se é uma aplicação mobile ou web, o nosso domínio tem que estar separado. Independente de database, o banco de dados, se tivermos um relacional, quisermos trocar para um NoSQL, também tem que ser possível fazer isso sem traumas. E independente de qualquer outro agente externo.

Conclusão e Próximos Passos

Essa proposta de arquitetura é para que o nosso domínio seja realmente o núcleo daquilo que trabalhamos, que protejamos ele e possamos modificar qualquer um desses outros componentes a qualquer momento, sem dificuldade. E é isso que vamos aprender: vamos modelar a nossa aplicação de uma forma diferente e verificar se conseguimos atingir esses cinco itens.

Então, espero você para continuarmos os nossos estudos!

Conhecendo o projeto CodeChella - Preparando o ambiente

Aprendemos a parte front-end (interface) da nossa aplicação CodeShella. Agora, vamos analisar o nosso back-end (servidor). Esse back-end será disponibilizado para você através de um link. Vou mostrar como executar e o que temos por enquanto.

Aprendemos que o CodeChella é um site que tem várias funcionalidades, como venda, ingresso, evento. Para entender claramente o processo de transformar essa aplicação em uma aplicação com Clean Architecture, vamos focar apenas em usuários. Então, todo o nosso foco será apenas no cadastro de pessoas usuárias, a pessoa que vai comprar o ingresso.

Do lado esquerdo da aplicação, temos uma aplicação Spring, que está dividida conforme aqueles pacotes que você está acostumado a construir quando assiste aos nossos cursos. Temos um controller, model, repository, service. E temos a nossa aplicação principal denominada CodechellaApplication que podemos executar.

Em application.properties, temos os dados para você conectar com o banco de dados.

application.properties

spring.datasource.url=jdbc:postgresql://localhost/codechella_db
spring.datasource.username=postgres
spring.datasource.password=1234
spring.datasource.driver-class-name=org.postgresql.Driver

hibernate.dialect=org.hibernate.dialect.HSQLDialect

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.format-sql=true
server.port=8081

Para executar essa aplicação do curso, você vai precisar utilizar um banco de dados PostgreSQL.

Vamos deixar textualmente o passo a passo para você instalar e configurar.

Observe que está referenciando um banco de dados chamado codechella_db. Minha senha e o usuário do banco, os drivers, estão aqui. Então, você vai precisar trocar e colocar a sua senha do banco.

No banco, para o Postgres, precisamos criar manualmente a aplicação. Diferentemente do MySQL, que geralmente o Spring já consegue criar para nós. Para isso, clicamos com o botão direito em “postgres” do lado esquerdo e escolhemos as opções “create > database”.

Será exibida uma janela, em que digitamos "codechella_db" no campo "DataBase", e criamos selecionando o botão azul "Save" no canto inferior direito. Quando executarmos a aplicação, ela já vai criar a tabela para nós.

Iniciamos a execução da aplicação Codechella Application no editor de código, clicando no ícone de play localizado no canto superior direito. Isso vai iniciar o meu servidor Tomcat, e então poderemos acessar a aplicação.

Ao acessarmos pelo navegador, por exemplo, através da porta 8081, o usuário estará vazio.

localhost:8081/usuarios

Obtemos como retorno da página:

[]

Para realizar o cadastro de uma pessoa usuária, utilizamos o Postman.

Cadastrando a pessoa usuária

Com o Postman aberto, para cadastrar um usuário naquele banco que foi criado agora, precisamos fazer uma requisição do tipo post para esse endpoint (ponto de acesso), que é o http://localhost:8081/usuarios.

http://localhost:8081/usuarios

Os campos obrigatórios são esses: CPF, nome, nascimento e e-mail.

{
  "cpf": "123.456.789-00",
  "nome": "Jacqueline Oliveira",
  "nascimento": "1990-09-09",
  "email": "jacqueline.alterdata@gmail.com"
}

Uma vez que você configurou no "body" o tipo JSON, basta clicar no botão azul "Send" (enviar) no canto superior direito do Postman. Assim, ele vai criar no banco.

Obtemos como retorno:

{
  "id": 1,
  "cpf": "123.456.789-00",
  "nome": "Jacqueline Oliveira",
  "nascimento": "1990-09-09",
  "email": "jacqueline.alterdata@gmail.com"
}

Trata-se do ID 1 e do usuário 1. É possível criar quantos usuários forem necessários apenas para garantir o funcionamento da aplicação, pois à medida que fazemos alterações e convertemos a aplicação para a Clean Architecture, será necessário testar novamente para garantir que tudo continue funcionando corretamente.

Conclusão e Próximos Passos

Espero que você configure corretamente o seu projeto no IntelliJ. Aos poucos, vamos passar por todas essas classes, detalhar elas, transformar elas usando a arquitetura do Clean. Começaremos em breve. Configure o seu ambiente que estamos esperando!

Sobre o curso Arquitetura Java: descomplicando a Clean Architecture

O curso Arquitetura Java: descomplicando a Clean Architecture possui 137 minutos de vídeos, em um total de 50 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:

Aprenda Java acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas