API Cartoraria
Find a file
2025-09-16 08:53:55 -03:00
abstracts deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
actions deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
config fix(Ajustes): Ajustes diversos 2025-08-21 15:34:43 -03:00
database deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
packages [MVPTN-5] feat(CRUD): Crud completo para a tabela g_tb_txmodelogrupo 2025-09-16 08:53:55 -03:00
storage fix(Ajustes): Ajustes diversos 2025-08-21 15:34:43 -03:00
.gitattributes deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
.gitignore Atualização de GitIgnore 2025-09-11 17:23:12 -03:00
Dockerfile deploy(fix): Ajuste no dockerfile 2025-08-07 14:22:16 -03:00
main.py deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
Orius.postman_collection.json [BE-03] feat(crud): adiciona crud de usuários 2025-08-13 10:22:43 -03:00
README.md deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
requirements.txt deploy(feat) Ajuste na estrutura de pasta 2025-08-07 12:22:16 -03:00
server.bat deploy(fix): ajuste de pydantic 2025-08-07 13:03:17 -03:00

🧩 Projeto [SAAS]

Este projeto é uma API monolítica modular, onde cada módulo representa um domínio específico da aplicação. Internamente, cada módulo é construído sobre a Arquitetura Hexagonal, promovendo separação de responsabilidades, testabilidade e independência da infraestrutura.


⚙️ Visão Geral da Arquitetura

🏗️ Estrutura Monolítica Modular

  • Modelo monolítico, modularizado por domínios
  • Cada domínio organizado dentro do diretório packages/
  • Componentes por domínio:
    • Controllers (entrada)
    • Endpoints (rotas)
    • Schemas (validação e transformação)
    • Actions (orquestração de lógica)
    • Services (casos de uso)
    • Repositories (acesso a dados)

🧭 Arquitetura Hexagonal por Módulo

/<domínio>
  /actions        # Orquestra lógica entre services, schemas e repositories
  /controllers    # Interface entre endpoints e actions
  /endpoints      # Define as rotas da API
  /repositories   # Acesso ao Firebird via SQLAlchemy
  /schemas        # Entrada e saída de dados
  /services       # Casos de uso

🛠️ Tecnologias Utilizadas

  • Linguagem: Python 3.11+
  • ORM: SQLAlchemy
  • Banco de Dados: Firebird
  • Driver: fdb
  • Arquitetura: Hexagonal por módulo
  • Organização: Modular por domínio

🗄️ Banco de Dados

O projeto utiliza Firebird como banco principal.

Arquivo de configuração:

Api/config/database/firebird.json

Exemplo:

{
  "host": "localhost",
  "port": 3050,
  "database": "/caminho/para/database.fdb",
  "user": "SYSDBA",
  "password": "masterkey"
}

Classe de conexão:

Api/core/connections/firebird.py

🧠 SQLAlchemy com Queries Manuais

Utilizamos SQLAlchemy para:

  • Gerenciar conexões
  • Preencher parâmetros em queries nativas

Exemplo:

sql = "SELECT * FROM CLIENTES WHERE ID = :id"
params = {"id": 123}
result = session.execute(text(sql), params).fetchall()

🗂️ Estrutura de Diretórios

Api/
├── api/
│   └── v1/
│       ├── packages/
│       │   └── administrative/
│       │       ├── actions/
│       │       ├── controllers/
│       │       ├── endpoints/
│       │       ├── repositories/
│       │       ├── schemas/
│       │       └── services/
│       └── api.py
├── config/
│   └── database/firebird.json
├── core/
│   ├── base/
│   ├── connections/
│   ├── system/
│   ├── utils/
│   └── auth.py

▶️ Executando a API

# Criar ambiente virtual
python -m venv .venv

# Ativar ambiente virtual
source .venv/bin/activate       # Linux/macOS
.venv\Scripts\activate        # Windows

# Instalar dependências
pip install -r requirements.txt

# Executar a API
uvicorn api.v1.api:app --reload

📌 Observações

  • Novos domínios devem seguir a estrutura modular.
  • A arquitetura hexagonal facilita manutenção e futura extração para microsserviços.
  • A separação entre actions, services e repositories melhora a organização e testabilidade.

👨‍💻 Autor

Desenvolvido por Orius Tecnologia
GitHub / LinkedIn: seu-link