O Esqueceram AI é um sistema de achados e perdidos desenvolvido para facilitar a recuperação de objetos. O sistema permite que usuários registrem itens perdidos ou encontrados, adicionem características e fotografias, pesquisem registros e recebam avisos quando houver uma possível correspondência.

A arquitetura foi definida buscando:

• separar responsabilidades;
• reduzir o acoplamento entre os módulos;
• facilitar manutenção e evolução;
• permitir testes independentes;
• facilitar a implementação dos padrões de projeto;
• integrar serviços externos para imagens e notificações;
• manter a implementação adequada ao escopo do projeto.

A organização segue uma abordagem top-down: primeiro são definidas as camadas principais do sistema e, depois, cada camada é dividida em módulos com responsabilidades específicas.

O sistema utiliza Arquitetura em Camadas (Layered Architecture), adaptada para uma aplicação web com backend centralizado.

As três camadas principais são:

1. Camada de Apresentação
2. Camada de Lógica de Negócio
3. Camada de Acesso a Dados

O backend será organizado como um monólito modular, ou seja, os módulos ficam dentro da mesma aplicação Flask, mas possuem responsabilidades separadas.

Além dessas camadas, existem integrações com serviços externos para armazenamento de imagens e envio de notificações.

flowchart TB
    U[Usuário]

    subgraph PRESENTATION["Camada de Apresentação"]
        WEB["Aplicação Web<br/>HTML + CSS + JavaScript"]
    end

    subgraph BUSINESS["Camada de Lógica de Negócio"]
        AUTH["Acesso e Perfil"]
        ITEMS["Gestão de Itens"]
        SEARCH["Busca e Filtros"]
        MATCH["Match"]
        NOTIF["Notificações"]
        COLLECTION["Postos de Coleta"]
        REWARD["Recompensas"]
        RECOVERY["Recuperação"]
    end

    subgraph DATA["Camada de Acesso a Dados"]
        REPO["Repositories"]
    end

    DB[("PostgreSQL")]

    subgraph EXTERNAL["Serviços Externos"]
        STORAGE["Firebase Storage"]
        FCM["Firebase Cloud Messaging"]
    end

    U --> WEB
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| AUTH
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| ITEMS
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| SEARCH
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| MATCH
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| COLLECTION
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| REWARD
    WEB -->|"HTTPS / REST / JSON<br/>(multipart para fotos)"| RECOVERY

    AUTH --> REPO
    ITEMS --> REPO
    SEARCH --> REPO
    MATCH --> REPO
    COLLECTION --> REPO
    REWARD --> REPO
    RECOVERY --> REPO
    REPO --> DB
    ITEMS --> STORAGE
    MATCH --> NOTIF
    NOTIF --> FCM
    FCM -->|"Push Notification"| WEB

A camada de apresentação é responsável pela interação direta com o usuário.

O frontend será desenvolvido com HTML, CSS e JavaScript, por se tratar de uma aplicação web.

Suas principais responsabilidades são:

• cadastro e login;
• cadastro de item perdido;
• cadastro de item encontrado;
• inserção de descrição e características;
• envio de fotografias;
• busca e aplicação de filtros;
• visualização de possíveis correspondências;
• confirmação de propriedade;
• acompanhamento da reserva;
• consulta de postos de coleta;
• acompanhamento de recompensas;
• recebimento de notificações.

A camada de apresentação não acessa diretamente o PostgreSQL. Toda comunicação com o backend ocorre por meio da API.

A camada de lógica de negócio concentra as regras responsáveis pelo comportamento do sistema.

Ela será organizada em serviços especializados, como:

• UsuarioService;
• ItemService;
• BuscaService;
• MatchService;
• NotificacaoService;
• PostoColetaService;
• RecompensaService;
• RecuperacaoService.

Nessa camada ficam as regras para cadastro, validação, comparação de características, geração de matches, notificações, reserva, confirmação de propriedade, devolução e recompensas.

A camada de acesso a dados é responsável por persistir e recuperar as informações do sistema.

O banco utilizado será o PostgreSQL.

O acesso ao banco será abstraído por repositórios, como UsuarioRepository, ItemRepository, MatchRepository, PostoColetaRepository e RecompensaRepository.

A regra de acesso será:

Controller
    ↓
Service
    ↓
Repository
    ↓
PostgreSQL

O frontend nunca acessa diretamente o banco de dados.

A comunicação entre frontend e backend ocorrerá por meio de uma API REST, utilizando HTTPS e chamadas assíncronas. Requisições sem arquivos usarão JSON; o cadastro de item com fotografia usará multipart/form-data.

Exemplo:

Aplicação Web
      |
      | POST /api/itens
      | multipart/form-data
      v
ItemController
      |
      v
ItemService
      |
      v
ItemRepository
      |
      v
PostgreSQL

Os módulos internos do backend devem se comunicar por meio de serviços, interfaces e eventos quando necessário, evitando dependência direta entre detalhes de implementação.

O Firebase Cloud Messaging (FCM) será utilizado para enviar notificações quando ocorrerem eventos relevantes, principalmente quando um possível match for identificado.

O Firebase Storage será utilizado para armazenar as fotografias dos itens. O PostgreSQL mantém os dados estruturados e o caminho do objeto necessário para acessar a imagem. O backend utiliza o Firebase Admin SDK com credenciais privilegiadas, que não são enviadas ao navegador.

O padrão arquitetural adotado é a Arquitetura em Camadas, combinada com um backend monolítico modular.

A escolha foi adaptada à realidade do projeto. Não será adotada uma arquitetura de microsserviços, pois ela acrescentaria complexidade operacional sem necessidade para o escopo acadêmico.