API Rest do projeto Ecommerce
Com essa opção não é necessário instalar o Java, gradle e nem o MongoDB, basta ter o docker compose, os dados de produtos iniciais já serão carregados no banco.
docker-compose up
Se precisar alterar o código basta buildar a aplicação novamente.
docker-compose build
É necessário instalar
- Java 11
- Gradle 7.0.2
- MongoDB 4.4.6 (ou docker-compose up -d mongo)
Rodando a aplicação
./gradlew clean build && ./gradlew bootRun
Rodando os testes
./gradlew clean test
Rodando o checkstyle
./gradlew checkstyleMain checkstyleTest
Obs: Caso esteja com dificuldade de subir esse serviço por algum motivo, pode subir também a versão mockada executando npm run mock-api na pasta do api-gateway. A diferença entre essas versões é que a mockada não válida os dados de cartões e estoque no fechamento do pedido, mas o resto deve funcionar corretamente.
- Java 11 como linguagem base.
- Spring utilizando SpringMVC como framework MVC, SpringData como ORM, SpringBoot para setup.
- MongoDB como banco de dados no SQL.
- Gradle foi utilizado como gerenciador de dependências e plugins.
- Docker foi utilizado para criar um container com o objetivo de facilitar o startup do projeto evitando ter que instalar Java, MongoDB e Gradle.
- Testcontainers utilizado para criação de teste de integração possibilitando subir um MongoDB embedded e executar testes de ciclo completo.
- JUnit 5 utilizado para os testes unitários.
- Mockito utilizado para criar mock nos teste unitários.
Foi utilizado clean-architecture para desacoplar as regras de negócios de dependências externas como banco de dados, frameworks (Spring) e bibliotecas, mantendo a parte da camada core o mais pura possível apenas utilizando Java e bibliotecas de testes.
Dentro dessa arquitetura o projeto foi modularizado para evitar uso indevido de depêndencias.
Essa camada deve ser livre de dependências externas, mantendo nossas regras de negócios isoladas.
Representa uma entidade de negócio sem vínculos com banco de dados, pode possuir regras de negócios mais genéricas e atributos sem a necessidade de ser um modelo anêmico.
Interface que abstrai a manipulação (Busca, Inclusão, Alteração e Remoção) de dados, seja em banco, outro serviço ou arquivo. Essa camada deve ser implementada na camada de infrastructure mantendo a inversão de depêndecia.
Representa uma ação de negócio, geralmente seguindo o padrão de projeto Command, utiliza das camadas de repository e entity.
Utilizado para orquestrar os UseCases e expô-los nas camadas acima. Como uma decisão minha, preferi não utilizar use case diretamente em outras camadas e sim o service, facilitando a injeção de dependência.
Exceções de negócio que estendem apenas exceções do próprio Java e devem ser tratadas na camada de infrastructure.
Essa camada trata de converter as entidades de neǵocios em modelos de banco e DTOs utilizados nas camadas de infrastructure. Nessa camada já possuímos um mínimo de influência de frameworks, geralmente de anotações de ORM.
Modelo que representa um dado de um repositório. Nesse projeto foi utilizado para mapear as entidades do MongoDB.
Conversor de Modelo para Entity e vice-versa.
Classe abstrata que estende das interfaces Repository utilizando os ModelAdapter para conversão da entidade para modelo e vice-versa. Ainda não implementa a lógica de repository real, por isso utiliza o padrão de projeto template criando métodos que serão implementados na camada de infrastructure.
Representa um DTO de saída de dados e estende de OutputMapper, implementando a lógica de conversão de entidade de negócio para o OutputData.
Representa um DTO de entrada de dados e estende de InputMapper, implementando a lógica de conversão de InputData para a entidade de negócio.
Nessa camada mantemos todas as dependências de bibliotecas, frameworks ou estruturas externas.
Interface contendo os métodos de acesso ao banco de dados, pode estender do MongoRepository do SpringBoot que possui diversos métodos implementados. A implementação dessa classe é de responsabilidade do SpringData e é feito em tempo de execução de acordo com o padrão de nome dos métodos e argumentos.
Implementa os métodos criados com o padrão de projeto template do nosso RepositoryAdapter chamando o MongoRepository, tem objetivo criar uma ponte entre essas duas partes.
Camada que contém as fábricas de services e é através dela que o Spring irá fazer a injeção de dependência desses módulos.
Responsável por tratar as exceptions de negócios lançando exceções que o Spring entenda, com isso conseguimos definir corretamente o retorno de status e corpo nos nossos endpoints rest.
É onde definimos nossos endpoints rest utilizando o SpringMVC e todas as camadas acima.
- Postman - collection com os endpoints da API
- DefaultData - Dados que são carregados ao subir a aplicação a primeira vez.