Repository for the FIAP Tech Challenge 4, focused on developing a microservice backend system for managing orders after the payment of a user is approved in a fast-food restaurant.

Tech Challenge 4 specifications can be found here. Youtube video explaining this project can be found here

This project is part of a larger system that includes:

• Customer Service - Microservice responsible to authentication and management of customers
• Order Service - Microservice responsible to manage new orders, products, categories
• Payment Service - Microservice responsible to manage order checkout and comunicating with external payment service
• Infrastructure - Terraform - Project responsible of create infrastructure to support all TC4 microservices.
• Infrastructure - Deploy - Project responsible to publish the microservices into Kubernetes

• Customer (actor): Actor responsible for initiating the purchasing process
• Cook (actor): Actor responsible for preparing the customer's order
• Attendant (actor): Actor responsible for interacting with the customer, providing support for the order
• Identification method: Format in which the customer is identified on the platform: via CPF or anonymous.
• Identification: Customer identification on the platform
• Authorization: Grants permission to the customer to perform operations on the platform, such as placing an order, changing registration information
• Order: Represents all items selected by the customer in the store
• Order Status: Represents the stage of order preparation after payment is confirmed.

.
├── bin
├── cmd
│   ├── server
│   └── worker
│       └── consumer
├── docs
├── internal
│   ├── adapter
│   │   ├── controller
│   │   ├── gateway
│   │   └── presenter
│   ├── core
│   │   ├── domain
│   │   │   ├── entity
│   │   │   └── value_object
│   │   ├── dto
│   │   ├── port
│   │   │   └── mocks
│   │   └── usecase
│   ├── infrastructure
│   │   ├── api
│   │   │   └── response
│   │   ├── aws
│   │   │   └── sqs
│   │   ├── config
│   │   ├── database
│   │   │   └── migrations
│   │   ├── datasource
│   │   │   └── model
│   │   ├── handler
│   │   │   ├── request
│   │   │   └── response
│   │   ├── httpclient
│   │   ├── logger
│   │   ├── middleware
│   │   ├── route
│   │   ├── server
│   │   └── setup
│   └── util
│       └── testdata
│           ├── common
│           ├── customer
│           ├── order
│           ├── order_product
│           ├── product
│           └── staff
├── mockserver
├── scripts
└── tests
    └── features

• Clean Architecture structure: The project was structured using the Clean Architecture pattern, which aims to separate the application into layers, making it easier to maintain and test. The project is divided into three layers: Core, Adapter, and Infrastructure.
• Presenter: The presenter (from Adapter layer) was created to format the data to be returned to the client. This layer is responsible for transforming the data into the desired format, such as JSON, XML, etc. Also, it is responsible for handling errors and returning the appropriate HTTP status code.
• Use Case: The use case (from Core layer) was created to define the business rules of the application. This layer is responsible for orchestrating the flow of data between the entities and the data sources.
• Middleware to handle errors: A middleware was created to handle errors and return the appropriate HTTP status code. This middleware is responsible for catching errors and returning the appropriate response to the client.
• Structured Logger: A structured logger was created to provide detailed logs. This logger is responsible for logging information about the application, such as requests, responses, errors, etc.
• Database Connection: The database connection was created using GORM, a popular ORM library for Go. This library provides an easy way to interact with the database and perform CRUD operations.
• Database Migrations: Database migrations were created to manage the database schema. This allows us to version control the database schema and apply changes to the database in a structured way.
• HTTP Server: The HTTP server was created using the Gin framework, a lightweight web framework for Go. This framework provides a fast and easy way to create web applications in Go.

(back to top)

• Dockerfile: small image with multi-stage docker build, and multi-platform build (Cross-Compilation)
• Makefile: to simplify the build and run commands
• Clean architecture
• PostgreSQL database
• Conventional commits

• Go
• Gin Web Framework
• golangci-lint
• golang-migrate
• govulncheck
• godoc

• Docker

• Go
• Docker

(back to top)

git clone https://github.com/FIAP-SOAT-G20/tc4-kitchen-service.git

cd tc4-kitchen-service

Set the environment variables

cp .env.example .env

make compose-build

(back to top)

make compose-up

(back to top)

1. Install Go: https://golang.org/doc/install
2. Clone this repository: git clone https://github.com/FIAP-SOAT-G20/tc4-kitchen-service
3. Change to the project directory: cd tc4-kitchen-service
4. Checkout to the development branch: make new-branch
5. Set the environment variables: cp .env.example .env
6. Install dependencies by running make install
7. Run the application by running make run-air or make run
8. Access the application at http://localhost:8080
9. Make your changes 🧑‍💻
10. Dont forget to run the tests by running make test
11. Check the coverage report by running make coverage
12. Check the lint by running make lint
13. Update the swagger documentation by running make swagger
14. Commit your changes following the Conventional Commits standard
15. Push to the branch and Open a new PR by running make pull-request
16. The GitHub Actions will run the tests, lint and vulnerability check automatically
17. After the PR is approved, merge it to the main branch
18. Generate a new release tag (here) with semantic versioning

(back to top)

Our project implements a comprehensive testing strategy that ensures code quality and reliability. We use multiple testing approaches to cover different aspects of the application.

The project maintains a high test coverage of 82.9%, demonstrating our commitment to code quality and reliability.

• Framework: Testify
• Coverage: Core business logic, use cases, and adapters
• Command: make test or make coverage

We use Godog framework to implement BDD tests that ensure our application behaves correctly from a user perspective.

# Run all tests
make test

# Run tests with coverage
make coverage

# Run BDD tests
make test-bdd

tests/
├── features/          # BDD feature files
│   └── order.feature
└── order_step_definition.go

internal/
├── adapter/
│   ├── controller/
│   │   ├── *_test.go
│   ├── gateway/
│   │   ├── *_test.go
│   └── presenter/
│       ├── *_test.go
├── core/
│   ├── domain/
│   │   ├── entity/
│   │   │   ├── *_test.go
│   │   └── value_object/
│   │       ├── *_test.go
│   └── usecase/
│       ├── *_test.go
└── infrastructure/
    ├── handler/
    │   ├── *_test.go
    ├── database/
    │   ├── *_test.go
    └── datasource/
        ├── *_test.go

• Mocking: Using gomock for interface mocking
• Fixtures: Test data fixtures for consistent testing
• Golden Files: Expected output validation
• Test Suites: Organized test execution
• Coverage Reports: Detailed coverage analysis

(back to top)

Alice Tomaz

Filipe Leuch Bonfim

Hugo Kishi

Marcos Santos

Matheus

(back to top)