Skip to main content

ADR-0002 — Modelo Organizacional Hierárquico

Status​

Aprovado

Contexto​

O sistema EBDbe não atenderá apenas uma única igreja isolada, mas poderá ser utilizado por diferentes ministérios.

Cada ministério possui uma estrutura hierárquica administrativa composta por igrejas que podem se subordinar a outras igrejas (relação pai-filha), sem limite fixo de profundidade.

Cada unidade possui gestão local dentro de sua competência, porém todas permanecem vinculadas ao respectivo ministério.

O sistema deve refletir essa estrutura organizacional de forma nativa, permitindo:

  • Administração local descentralizada
  • Visibilidade consolidada em nível ministerial
  • Isolamento de dados por unidade
  • Governança hierárquica

Portanto, o modelo anterior com níveis nominais fixos de unidade não é suficiente.

Decisão​

O sistema adotará modelo organizacional hierárquico multinível, com as seguintes entidades estruturais (conforme ADR-0005):

Ministry └── OrganizationalUnit └── parent_unit_id: referência opcional para outra OrganizationalUnit

Além da hierarquia interna, cada Ministry é tratado como tenant lógico com domínio(s) próprio(s) de entrada, conforme ADR-0012.

Todas as entidades de domínio estarão vinculadas a uma unidade organizacional específica. A entidade genérica OrganizationalUnit representa um nó de igreja na árvore administrativa.

Os campos detalhados de OrganizationalUnit (code, phone, email, address, pastor_id, secretary_id, foundation_date etc.) constam no ADR-0005.

1. Identificação Organizacional​

Toda entidade persistida deverá conter:

  • ministry_id
  • unit_id (identificador da unidade local)

O unit_id referencia uma OrganizationalUnit em estrutura de árvore recursiva, com parent_unit_id opcional.

O modelo é estruturado de forma genérica para permitir expansão futura com profundidade ilimitada.

Para entrada HTTP/Web, o tenant ministerial também será identificado pelo domínio da requisição e validado contra o ministry_id efetivo da operação.

2. Hierarquia e Escopo de Gestão​

O escopo de atuação será definido por relação hierárquica entre unidades:

  • Ministério: visão global e consolidada do tenant.
  • Unidade local: gestão de si e, quando autorizado por papel, de unidades descendentes.

A visibilidade de dados obedecerá à hierarquia.

Unidades inferiores não terão acesso a dados de unidades ancestrais ou ramos paralelos sem autorização explícita de papel e escopo.

3. Modelo de Isolamento de Dados​

O isolamento será implementado por:

  • Validação obrigatória de escopo no backend
  • Regras de segurança no Firestore
  • Controle de acesso baseado em papel e escopo organizacional
  • Resolução e validação de tenant por domínio

Nenhuma consulta poderá ser realizada sem validação de:

  • Papel do usuário
  • Unidade organizacional vinculada
  • Relação hierárquica entre unidade de origem e unidade-alvo
  • Coerência entre domínio de entrada e ministry_id autorizado

4. Estrutura Conceitual​

Modelo simplificado (nomenclatura conforme ADR-0005):

Ministry ├── OrganizationalUnits │ └── (árvore recursiva de igrejas via parent_unit_id) │ ├── Users ├── ClassGroups ├── Lessons ├── Attendances └── Materials

As entidades de negócio sempre estarão associadas a uma unidade organizacional.

5. Escalabilidade​

Este modelo permite:

  • Expansão para múltiplos ministérios
  • Crescimento orgânico da estrutura
  • Profundidade organizacional ilimitada
  • Governança descentralizada
  • Consolidação ministerial

6. Princípio Estrutural​

O sistema nasce preparado para estrutura organizacional complexa.

Mesmo que inicialmente seja utilizado por apenas uma igreja, o modelo hierárquico por árvore autorrelacionada é estrutural e não opcional.

Consequências​

  • Toda operação deverá validar escopo organizacional.
  • O controle de acesso dependerá não apenas de papel, mas também de unidade.
  • O modelo de dados será orientado a hierarquia.
  • Futuras alterações estruturais exigirão novo ADR.
  • O cadastro e governança de domínios ministeriais tornam-se parte da operação da plataforma.
Last updated on