Skip to main content

ADR-0001 — Arquitetura Geral do Sistema

Status​

Aprovado

Contexto​

O projeto EBDbe tem como objetivo fornecer uma plataforma digital para controle e gestão da Escola Bíblica Dominical (EBD), com uso predominante em dispositivos móveis e necessidade de:

  • Acesso simplificado via celular
  • Baixo atrito para usuários não técnicos
  • Escalabilidade para múltiplas igrejas
  • Controle hierárquico de papéis
  • Registro estruturado de aulas e frequência
  • Preservação de privacidade

A arquitetura precisa ser:

  • Simples de manter
  • Escalável
  • Modular
  • Compatível com desenvolvimento incremental
  • Adequada ao uso intensivo de dispositivos móveis

Decisão​

A arquitetura oficial do sistema será composta por:

1. Modelo Arquitetural​

Arquitetura Web Mobile-first com backend serverless.

Estrutura lógica:

[ Flutter Web (PWA) ] ↓ [ Firebase Authentication ] ↓ [ Tenant Resolver (domínio -> ministry_id) ] ↓ [ Cloud Functions (TypeScript) ] ↓ [ Firestore ]

2. Frontend​

O frontend será desenvolvido utilizando:

  • Flutter Web (Dart)
  • Configurado como Progressive Web App (PWA)
  • Estruturado seguindo princípios de Clean Architecture simplificada

Objetivos do frontend:

  • Interface otimizada para dispositivos móveis
  • Instalação opcional como aplicativo (via PWA)
  • Separação clara entre camadas de domínio, aplicação e apresentação
  • Comunicação exclusiva com backend via APIs

3. Backend​

O backend será baseado na plataforma Firebase, utilizando:

  • Firebase Authentication para autenticação
  • Firestore como banco de dados NoSQL
  • Cloud Functions escritas em TypeScript para lógica de negócio
  • Firebase Emulator para desenvolvimento local

Características:

  • Arquitetura serverless
  • Escalabilidade automática
  • Separação entre regras de domínio e infraestrutura

4. Separação de Responsabilidades​

O frontend:

  • Não conterá regras críticas de negócio
  • Apenas orquestrará fluxos e validações básicas

O backend:

  • Será responsável por todas as regras de negócio
  • Aplicará controle de acesso
  • Validará presença
  • Garantirá isolamento multi-igreja
  • Resolverá tenant por domínio de entrada e escopo autorizado

5. Estrutura Física do Repositório​

A organização seguirá o padrão:

ebdbe/ │ ├── frontend/ │ ├── lib/ │ │ ├── core/ │ │ ├── domain/ │ │ ├── application/ │ │ ├── infrastructure/ │ │ ├── presentation/ │ │ └── shared/ │ │ │ ├── test/ │ └── web/ │ ├── backend/ │ ├── functions/ │ │ ├── domain/ │ │ ├── application/ │ │ ├── infrastructure/ │ │ ├── interfaces/ │ │ └── shared/ │ │ │ ├── tests/ │ └── emulator/ │ ├── docs/ │ ├── architecture/ │ │ └── adrs/ │ ├── diagrams/ │ └── models/ │ └── README.md

6. Princípios Arquiteturais​

  1. Mobile-first como prioridade.
  2. Backend como autoridade de negócio.
  3. Separação clara entre camadas.
  4. Evolução incremental via ADR.
  5. Multi-igreja como requisito estrutural.
  6. Privacidade como premissa arquitetural.
  7. Multitenancy por domínio com validação obrigatória de escopo.
  8. Administração global somente via papel e trilha auditável.

Consequências​

  • O sistema não dependerá de publicação em loja de aplicativos.
  • O frontend poderá evoluir para aplicativo nativo no futuro sem ruptura arquitetural.
  • A escalabilidade será gerenciada pela infraestrutura Firebase.
  • A lógica de negócio estará centralizada e auditável no backend.
  • Toda modificação estrutural futura exigirá novo ADR.
  • O roteamento por domínio passa a influenciar a resolução de contexto (ministry_id).
  • Referência complementar: ADR-0012 (multitenancy por domínio e PLATFORM_ADMIN).
Last updated on