Mapa de módulos e dependências

1 · Módulos do município

Atalhos de combinação, ou clique em cada módulo.

2 · Quem depende de quem

dependência atendida seria atendida se os dois lados estivessem ativos bloqueado

A seta aponta de quem é exigido para quem exige. Contratos e Pedidos precisam de Estoque e/ou Patrimônio: basta um dos dois.
Todo módulo depende do Núcleo; a seta só aparece onde o Núcleo é a única exigência.
Relatórios não exige um módulo específico, só que exista algum para mostrar.
O sistema bloqueia nos dois sentidos: não liga sem o que o módulo exige, e não desliga o que outro módulo ativo ainda exige.

3 · O que some do menu

Menu lateral de quem tem todas as permissões

Santarém · SEMTRAS

Esconder o menu não basta. O middleware modulo:<nome> fecha as rotas e a API do módulo desligado, antes mesmo de olhar a permissão. As tabelas continuam existindo, vazias ou cheias, porque o esquema do banco é o mesmo para todos os municípios.

4 · Telas que cruzam módulos

Cada tela precisa funcionar com menos, sem erro. Estas são as que juntam mais de um módulo.

Como os módulos conversam: eventos de domínio

Nenhum módulo lê a tabela de outro. Quem faz algo publica um evento, e quem estiver ativo e interessado reage.

Por isso Estoque e Patrimônio não têm chave estrangeira para Contratos nem Pedidos: o vínculo é guardado como referência, sem constraint (ver 04-modelo-de-dados.html).

Regras de implementação

Monólito modular: um deploy, um módulo por pasta, tabelas próprias.
Esquema único: ativar ou desativar só muda o acesso (menu, rotas e API). Nenhuma tabela é criada ou removida.
Desativar esconde, não apaga: os dados ficam e a auditoria continua valendo.
Dependências no código: cada módulo declara o que exige, e o cadastro de módulos do município valida isso ao ligar e desligar.
Regra de negócio é configuração: “entrada exige contrato” e o número de etapas de autorização são ajustes do município, não módulos.
Licenciamento: o cadastro de módulos por município deixa espaço para vigência e plano, sem implementar cobrança agora.

Riscos que esta página ajuda a enxergar

Granularidade: seis módulos já geram várias combinações válidas de teste; por isso são só seis.
Acoplamento escondido: leitura direta de tabela de outro módulo quebraria o “desligar sem afetar”.
Telas que cruzam módulos: a seção 4 mostra o comportamento esperado de cada uma.
Consumo e permanente no mesmo pedido: com um módulo só, catálogo e pedido filtram o tipo correspondente.

Pontos assumidos nesta página, a confirmar

Desligar um módulo que outro ainda exige: a página bloqueia e pede para desligar o outro antes. A análise só diz que o sistema impede ligar sem as dependências. A alternativa é desligar em cascata, com aviso.
Relatórios: a análise diz que depende dos “módulos ativos”. Aqui exige ao menos um outro módulo ligado, e a lista de relatórios por módulo é uma proposta.
Entrada de estoque sem Contratos: a regra “entrada exige contrato” não tem como valer sem o módulo. A página assume que, nesse caso, só existe a entrada manual com justificativa.
Quem liga e desliga módulos: a página de perfis atribui config.gerenciar ao Administrador do município. Quando houver venda por módulo, talvez isso passe a ser feito só pela equipe do sistema.
A SEMTRAS começa com todos os módulos ligados? O MVP tem relatórios só básicos, então Relatórios pode entrar reduzido.

Módulos e dependências conforme a seção 6 da análise · municípios, contagens e combinações fictícios · fonte: docs/requisitos/analise-requisitos.md, seção 6. Menu e perfis em docs/fluxos/05-perfis-e-permissoes.html.