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.