Arquitetura¶

A OpsFactor separa governança de dados, modelos de planejamento, execução longa e experiências de decisão. Essa divisão mantém a jornada rastreável desde as fontes até o plano versionado e suas interpretações física e econômica.

Mapa de responsabilidades¶

Camada	Responsabilidade	Contrato durável
Experiência de decisão	Configurar, executar, analisar, colaborar, aprovar e explicar	APIs e objetos de planejamento versionados
Serviços de aplicação	Validar comandos, coordenar casos de uso, controlar transações e publicar resultados	Requests tipados, erros e ciclo de task
Engines de planejamento	Demanda, MPS/MRP, otimização, simulação de estoque, sequenciamento e finanças	Entradas, premissas, séries e saídas
Snapshot de planejamento	Visão consistente em memória de dados mestres, transacionais, configuração e planos anteriores	Granularidade, chave, unidade, calendário e versão
Persistência e integração	Dados governados, saídas, auditoria e status de integração	Catálogo de dados

Da requisição à decisão¶

Usuário ou integração seleciona objeto de planejamento, escopo, horizonte e configuração.
A aplicação valida referências e cria ou reutiliza o cabeçalho versionado.
Factories carregam os registros em lote e os indexam em um snapshot consistente.
A engine escolhida executa sem consultar uma entidade por vez.
Resultados são materializados em famílias como Demand Plan, Supply Plan, produção, distribuição, estoque ou fatos econômicos.
Planning Books e visões analíticas leem os resultados persistidos.
Modificações aprovadas passam pelo serviço oficial para recalcular quantidades dependentes.
A versão liberada ou Working Plan alimenta o processo seguinte.

A fronteira do snapshot é importante: um cálculo não pode misturar silenciosamente dados carregados em momentos diferentes ou unidades incompatíveis.

Engines e semântica dos planos¶

As engines têm significados matemáticos diferentes:

Demand Planning estatístico estima demanda futura com histórico e sinais configurados;
MPS/MRP heurístico percorre dependências e capacidades segundo prioridades explícitas;
otimização Enterprise compara alternativas simultaneamente sob restrições e objetivo;
Inventory Optimization usa simulação estocástica e curvas de sensibilidade;
Line Sequencing resolve alocações temporais e combinatórias detalhadas;
Finance interpreta fatos físicos persistidos e propaga efeitos econômicos.

Em Supply Planning, as séries públicas usam Unconstrained Plan, Constrained Plan e Working Plan. Um plano restrito heurístico é um resultado viável por regras; não é uma afirmação de ótimo global.

Execução de longa duração¶

Cálculos que podem exceder uma requisição interativa rodam como tasks observáveis. A task deve expor operação, referência do plano, status, timestamps, progresso quando disponível e falha acionável.

O serviço de aplicação controla transações de criação, limpeza e materialização. Uma nova execução com falha não deve aparecer como plano concluído. Quando artefatos de diagnóstico são preservados, o estado permanece explícito.

Princípios de desempenho e consistência¶

carregar relacionamentos em lote e evitar consulta por linha;
reutilizar projections indexadas em cálculos e análises;
persistir grandes famílias de saída em batch;
manter conversões de unidade e calendário explícitas;
falhar diante de dado econômico ou conversão obrigatória ausente, sem substituir por zero plausível;
preservar baselines imutáveis e aplicar mudanças à versão de trabalho correta;
regenerar análises dependentes após mudanças materiais no plano físico.

Fronteira Community e Enterprise¶

A fundação Community controla contratos reutilizáveis, caminhos públicos de execução e pontos explícitos de extensão. Capacidades Enterprise consomem ou estendem essa fundação. O runtime Community não depende de entidades, tabelas ou implementações privadas.

Um rótulo de edição em tela não prova que a capacidade executa. Catálogos de runtime e a release versionada definem o que pode ser selecionado. As páginas funcionais trazem a comparação por domínio; a visão geral Community identifica a baseline pública.

Exemplos da divisão atual:

Demand Planning estatístico no Community; modelos estatísticos avançados e de AI no Enterprise;
MPS/MRP heurístico no Community; otimizador global e orquestração no Enterprise;
Planning Book agregado de produção no Community; Line Scheduling detalhado no Enterprise;
Deployment operacional de um fluxo no Community; analytics multi-item e formação de cargas no Enterprise;
Network Design, Inventory Optimization e Cost-to-Serve detalhado no Enterprise.

Segurança e tenancy¶

Autenticação, autorização, isolamento de tenants, auditoria, secrets e topologia são contratos de implantação. Devem ser publicados junto da distribuição que os implementa. A documentação funcional não implica que um checkout de código entregue sozinho um modelo operacional Enterprise.

Regras de extensão¶

Uma extensão válida declara:

contrato compartilhado implementado;
dados e validações necessários;
nova engine, saída, visão ou integração;
comportamento transacional e de limpeza;
disponibilidade por edição e runtime;
regressão e documentação da versão publicada.

Extensões privadas podem referenciar objetos compartilhados. O código compartilhado nunca referencia tipos privados.

Continue em Integração de dados, nas jornadas funcionais ou na arquitetura Community.