Skip to main content

ADR-0016 — OrganizationalUnit com Igrejas Autorelacionadas e Governança Funcional da EBD

Status​

Proposto

Contexto​

A modelagem organizacional anterior utilizava níveis nominais fixos de unidade (CHURCH, CONGREGATION, SUBCONGREGATION).

Na operação real, a estrutura é composta por igrejas com vínculo de subordinação administrativa (igreja filha), sem limite previsível de profundidade.

Além disso, a EBD possui uma governança funcional transversal que atua sobre todas as igrejas do ministério, coexistindo com a hierarquia administrativa.

Foi necessário consolidar:

  1. Modelo organizacional recursivo sem limite de níveis.
  2. Regras de escopo hierárquico por ancestralidade/descendência.
  3. Regras de governança funcional da EBD sem criar papéis redundantes.

Decisão​

O sistema adotará:

  1. Estrutura administrativa em árvore de igrejas autorrelacionadas

    • OrganizationalUnit representa um nó de igreja.
    • A relação hierárquica será definida por parent_unit_id (opcional).
    • A profundidade da árvore é ilimitada.
    • Não haverá tipificação estrutural fixa por CONGREGATION/SUBCONGREGATION.

  2. Escopo hierárquico por relação entre nós

    • Acesso e operação serão definidos por combinação de:
      • unidade do ator (unit_id)
      • unidade-alvo
      • relação entre elas: SAME, ANCESTOR, DESCENDANT, UNRELATED
    • Não há acesso lateral entre ramos não relacionados.

  3. Governança funcional da EBD em eixo transversal

    • O eixo funcional da EBD atravessa toda a árvore administrativa.
    • Papéis e permissões continuam baseados em ADR-0003 (RBAC + escopo).
    • O backend permanece autoridade de autorização.

1. Eixo Administrativo x Eixo Funcional​

1.1 Eixo Administrativo​

  • Baseado em Ministry -> OrganizationalUnit (árvore).
  • Define vínculo e alcance hierárquico das operações.

1.2 Eixo Funcional EBD​

  • Define responsabilidades da EBD (supervisão, secretaria, docência, assistência).
  • Não substitui validação de escopo organizacional.
  • Toda ação funcional deve respeitar ministry_id e unit_id válidos para o ator.

2. Governança Funcional da EBD​

2.1 Convenções Organizacionais (sem papel sistêmico obrigatório)​

  • Coordenador Geral EBD
  • Vice Coordenador Geral EBD

Esses cargos são convenções organizacionais e não exigem novo papel de sistema obrigatório, podendo ser representados por composição de papéis já existentes e políticas internas do ministério.

2.2 Secretaria Geral e Secretaria Local​

  • Secretaria pode ser composta por múltiplas pessoas.
  • A secretaria pode aprovar atribuições e cadastros "abaixo dela", respeitando RBAC e escopo hierárquico.
  • Aprovação sempre validada no backend.

2.3 Classes e Papéis Operacionais​

  • Classes da EBD são representadas por ClassGroup.
  • Professor: EBD_TEACHER.
  • Assistente de classe: EBD_ASSISTENT.

2.4 Equipes de Louvor e Introdução​

  • Serão tratadas como registro operacional da ocorrência da EBD.
  • Não recebem, por este ADR, permissões administrativas adicionais.

3. Regras de Aprovação e Alcance​

  1. Aprovação depende de papel com permissão funcional e escopo hierárquico compatível.
  2. "Abaixo dela" significa unidade-alvo descendente da unidade do aprovador (ou mesma unidade quando aplicável).
  3. Aprovação fora da cadeia hierárquica é proibida.
  4. Operações ministeriais devem respeitar política de escopo ministerial definida nos ADRs de segurança e RBAC.

4. Integração com ADRs Existentes​

  • ADR-0002: substitui níveis fixos por árvore recursiva.
  • ADR-0003: mantém RBAC, atualizando semântica de escopo para relação de ancestralidade.
  • ADR-0005: ajusta OrganizationalUnit para nó autorrelacionado sem tipos fixos.
  • ADR-0010: atualiza fluxo de ativação/aprovação para cadeia hierárquica por árvore.
  • ADR-0011: comunicações respeitam escopo por árvore.

Consequências​

  • O sistema fica aderente à realidade organizacional sem limite de níveis.
  • Regras de autorização tornam-se mais precisas por relação hierárquica real.
  • Evita proliferação de papéis por nomenclatura local.
  • Exige validação de ancestralidade/descendência no backend para operações sensíveis.
  • Mudanças futuras no modelo de escopo continuam exigindo ADR próprio.
Last updated on