Skip to main content

ADR-0007 — Padrão de Organização de Código

Status​

Aprovado

Contexto​

O sistema EBDbe será desenvolvido utilizando:

  • Flutter Web (frontend)
  • Firebase + Cloud Functions (backend)

Para evitar acoplamento excessivo, código desorganizado e crescimento caótico, é necessário definir um padrão estrutural claro para organização do código.

A estrutura deve:

  • Separar responsabilidades
  • Isolar domínio de infraestrutura
  • Facilitar testes
  • Permitir crescimento modular
  • Ser compreensível para novos colaboradores

Decisão​

O projeto adotará organização baseada em princípios de Clean Architecture simplificada, separando claramente:

  • Domain
  • Application
  • Infrastructure
  • Presentation (frontend)
  • Interfaces (backend)

1. Estrutura do Frontend (Flutter)

Estrutura oficial:

frontend/ └── lib/ ├── core/ ├── domain/ ├── application/ ├── infrastructure/ ├── presentation/ └── shared/

1.1 domain​

Contém:

  • Entidades
  • Value Objects
  • Regras puras de domínio
  • Interfaces abstratas

Não pode depender de Firebase ou Flutter.

1.2 application​

Contém:

  • Use cases
  • Orquestração de regras
  • Serviços de aplicação

Pode depender de domain, mas não de infraestrutura concreta.

1.3 infrastructure​

Contém:

  • Implementações de repositórios
  • Integração com Firebase
  • Adaptadores externos

Pode depender de domain e application.

1.4 presentation​

Contém:

  • Widgets
  • Controllers
  • State management
  • Rotas

Pode depender de application.

Nunca deve conter regra de negócio crítica.

1.5 core​

Contém:

  • Configurações globais
  • Inicialização
  • Tratamento de erros
  • Serviços base

1.6 shared​

Contém:

  • Componentes reutilizáveis
  • Utilitários
  • Constantes

2. Estrutura do Backend (Cloud Functions)

Estrutura oficial:

backend/ └── functions/ ├── domain/ ├── application/ ├── infrastructure/ ├── interfaces/ └── shared/

2.1 domain​

  • Entidades
  • Regras puras
  • Interfaces de repositório

Não depende de Firebase SDK.

2.2 application​

  • Casos de uso
  • Serviços de validação
  • Orquestração de lógica

2.3 infrastructure​

  • Implementação concreta de acesso ao Firestore
  • Integração com Firebase Auth
  • Logs

2.4 interfaces​

  • Entradas HTTP
  • Handlers de Cloud Functions
  • Validação de requisição
  • Mapeamento de DTOs

2.5 shared​

  • Utilitários
  • Tipos comuns
  • Constantes globais

3. Regras Estruturais

  1. Domain não depende de infraestrutura.
  2. Presentation não contém regra de negócio crítica.
  3. Backend valida todas as regras finais.
  4. Nenhuma função acessa Firestore diretamente fora da camada infrastructure.
  5. Não será utilizado padrão anárquico baseado apenas em “features soltas”.

4. Nomeação

  • Pastas internas em inglês.
  • ADRs em português.
  • Classes e arquivos em inglês.
  • Entidades com nomes claros e sem abreviações excessivas.

5. Testes

  • Testes unitários para domínio.
  • Testes de aplicação.
  • Uso do Firebase Emulator para backend.
  • Testes não devem depender de produção.

Consequências​

  • A estrutura impõe disciplina arquitetural.
  • Refatorações futuras serão mais seguras.
  • Novos colaboradores terão referência clara.
  • Crescimento desordenado será evitado.
Last updated on