FIAP Tech Challenge - Restaurant

Project Architecture by Clean Architecture

• app/web: diretório para os principais pontos de entrada, injeção dependência ou comandos do aplicativo. O subdiretório ‘web’ contém o ponto de entrada principal a API REST.
• domain/entities: diretório que contém modelos/entidades de domínio que representam os principais conceitos de negócios.
• domain/usecases: diretório que contém Serviços de Domínio ou Use Cases.
• domain/ports: diretório que contém ‘interfaces’ ou contratos definidos que os adaptadores devem seguir.
• adapters/payment: adaptador para meio de pagamento externo.
• adapters/delivery: adaptador para meio de entrega externo.
• frameworks/rest: diretório que contém os controllers e manipulador de requisições REST.
• frameworks/rest/dto: diretório que contém objetos/modelo de request e response.
• frameworks/repository: diretório que contém adaptadores de banco de dados exemplo para PostgreSQL.
• frameworks/repository/dbo: diretório que contém objetos/entidades de banco de dados.
• .infra: diretório que contém arquivos de infrainstrutura
• .infra/kubernetes: diretório que contém os manifestos kubernetes
• .infra/terraform: diretório que contém os arquivos terraform para provisionar a infra do projeto

Stack

• Go
• Domain-Driven Design
• Hexagonal Architecture
• Gin Web Framework - Routes, JSON validation, Error management, Middleware support
• PostgreSQL - Database persistence
• GORM ORM library for Golang
• Slog - Package slog provides structured logging, in which log records include a message, a severity level, and various other attributes expressed as key-value pairs.
• GoDotEnv - A Go (golang) port of dotenv project (which loads env vars from a .env file).
• Criptografia Simétrica AES

Desafios

• Implementação da Arquitetura Hexagonal
• Implementação de Conteinerização usando Docker e Docker Compose
• Implementação de Orquestração de Containers usando Kubernetes e AWS EKS
• Implementação de CI/CD usando Github Actions
• Implementação da Arquitetura de Microservices com comunicação Assincrôna usando mensageria
• Implementação de API Gateway AWS Gateway com Autenticação e Autorização usando AWS Lambda
• Implementação de Autenticação usando JWT
• Implementação de qualidade de código usando SonarLint, SonarQube e SonarCloud
• Implementação de Transações distribuídas usando o Padrão SAGA
• Distribuição de processos usando AWS Lambda
• Uso de IaaS(Infrastructure as a Service) usando Terraform

Motivações

Boas práticas e padrões usados para resolver os desafios

Justificativa do Padrão SAGA com Coreografia

Na implementação do padrão SAGA optei por usar a estratégia de Coreografia para fazer uso dos seguintes benefícios:

1. Desacoplamento e Autonomia dos Serviços Para que os serviços fiquem mais independentes uns dos outros e não dependam de um orquestrador central o que adicionaria outro ponto de falha. A ideia é que cada serviço conhece apenas sua própria lógica e como reagir a eventos específicos, permitindo maior autonomia no desenvolvimento e evolução dos serviços.

2. Escalabilidade Como não há um ponto central de controle, o sistema pode escalar melhor horizontalmente, já que o aumento na carga de trabalho passa ser distribuído entre os serviços, sem sobrecarregar um único orquestrador.

3. Resiliência A falha de um serviço não impede necessariamente que outros serviços continuem a operar. Cada serviço foi projetado para lidar com falhas de maneira mais isolada, aumentando a resiliência geral do sistema.

4. Flexibilidade e Evolução do Sistema Adicionar, modificar ou remover serviços é mais fácil e menos impactante, pois não há necessidade de alterar um orquestrador central. Isso tornou a arquitetura mais adaptável a mudanças de requisitos de negócios ou novas funcionalidades. Cada serviço pode ser desenvolvido e implantado de forma independente, o que facilita a adoção de novas tecnologias ou padrões sem impactar o sistema como um todo.

5. Melhor Alinhamento com Arquiteturas Orientadas a Eventos A coreografia alinhou bem com arquiteturas orientadas a eventos, onde os eventos dirigem o fluxo das operações, facilitando a implementação de arquiteturas reativas e altamente responsivas.

Instruções para rodar a aplicação local, usando docker-compose

Pré-requisitos: Ter docker, docker-compose e postman

1. Usando um terminal/powershell no diretório raiz da aplicação rodar docker-compose up
2. Importar no Postman a collection
3. Verificar se os serviços estão UP executando os endpoints:
   1. Health restaurant-api
   2. Health payment-api
   3. Health kitchen-api
4. Executar os endpoints na sequencia para criar o fluxo de pedidos:
   1. Orders/Start New Order
   2. Orders/Add Item
   3. Orders/Confirmation Order
   4. Orders/Send Order to Payment
   5. Payment/Paid by Order Id
   6. Kitchen/Ready
   7. Orders/Sent for Delivery Order
   8. Orders/Delivered Order

---

Setup Development

Dependencies

• Go Installation

Check for go version 1.21.3

go version

Preparing app

git clone git@github.com:fabianogoes/fiap-tech-challenge-restaurant-api.git
cd fiap-tech-challenge-restaurant-api
go mod tidy

Running to development

docker-compose up -d postgres && go run app/web/main.go

Testing using Docker/Docker Compose

docker-compose up -d

curl --request GET --url http://localhost:8080/health

## response 
{"status":"UP"}

Pre-registered data

Quando a ‘app’ subir será inserido dados necessários para testar a criação de pedidos

Para verificar a lista de produtos pode ser usado a API:

http://localhost:8080/products

Para verificar a lista de clientes pode ser usado a API:

http://localhost:8080/customers

Para verificar a lista de Atendentes pode ser usado a API:

http://localhost:8080/attendants

Collection

Docker Commands

docker login -u=fabianogoes
docker build -t fabianogoes/restaurant-api:latest .
docker tag fabianogoes/restaurant-api:latest fabianogoes/restaurant-api:latest
docker push fabianogoes/restaurant-api:latest

Run Coverage

clear && go test -coverprofile=coverage.out ./... &&  go tool cover -func=coverage.out