Informação e decisão: duas camadas

Durante algum tempo, a arquitectura tratava a criação de um documento como se fosse o fim de um processo.

Era uma simplificação útil. Estava também errada.

Um documento pode registar, comunicar ou provar alguma coisa. A consequência — aprovar, pagar, publicar ou rejeitar — pertence ao processo que o utiliza. Confundir os dois faz um sistema parecer concluído antes de a decisão importante ter realmente acontecido.

A diferença parece pequena. Na prática, altera o lugar da validação, da autoridade, do julgamento humano e da recuperação perante falhas.

Onde o modelo falhou

O problema tornou-se visível numa integração contabilística. A sequência pretendida era prudente: preparar informação num sistema, revê-la e só depois permitir uma acção externa com consequência fiscal.

A documentação pública da interface não permitia inicialmente provar que existia uma pausa com significado antes da finalização. Pareciam existir várias implementações possíveis, mas nenhuma estava verificada.

Essa incerteza definiu a primeira fronteira de produção. O sistema podia carregar os dados locais autoritativos, verificar permissões e coerência, preparar a referência externa e indicar se a informação estava pronta. Não podia escrever no sistema externo.

Não era automação incompleta disfarçada de arquitectura. Era uma fronteira explícita: avançar com aquilo que se conhecia e parar onde o contrato externo permanecia incerto.

O erro surgiu depois. Transformei um controlo desenhado para uma integração consequencial num modelo geral para todos os documentos.

O modelo não se adaptava bem a outros casos. Um contrato, um relatório operacional, um extracto importado e uma nota interna são documentos, mas não criam as mesmas obrigações nem exigem os mesmos controlos.

O caso era uma prova útil. Não era a categoria.

Duas responsabilidades, não um único ciclo de vida

O modelo revisto separa duas responsabilidades.

A primeira é a própria informação:

O que é este objecto?
Qual é a versão actual?
De onde veio a informação?
Quem pode aceder-lhe ou alterá-la?
Durante quanto tempo deve ser conservada?

A segunda é a decisão que a utiliza:

Quem tem autoridade para avançar?
O que precisa de ser verificado primeiro?
Que acontecimento cria a consequência real?
O que acontece se o resultado for rejeitado ou permanecer incerto?
Como confirmamos o que um sistema externo realmente fez?

As duas camadas relacionam-se, mas não avançam em conjunto. Um contrato pode chegar à quarta versão enquanto a revisão jurídica continua aberta. Um relatório pode estar final como registo e a decisão operacional que nele se apoia permanecer pendente. Um PDF pode preservar a prova de uma aprovação sem ser a própria aprovação.

Esta separação é coerente com normas estabelecidas de gestão documental e de processos. A ISO 15489 concentra-se na criação e gestão de registos. O W3C PROV distingue informação, actividade e responsabilidade. O BPMN separa os dados utilizados por um processo das actividades e decisões que fazem parte desse processo.

As normas validam a distinção. Não precisam de dominar o desenho.

O que mudou na arquitectura

O primeiro modelo parecia tranquilizadoramente linear: a informação entrava, passava pela validação, recebia aprovação e produzia um documento final.

O trabalho real era menos arrumado. Uma decisão podia ficar à espera, falhar, regressar para correcção ou depender de uma resposta externa que nunca chegava. O documento podia mudar sem reabrir a decisão; a decisão podia mudar sem produzir um novo ficheiro.

A arquitectura revista começa, por isso, com três perguntas:

Que informação tem de permanecer fiável?
Que decisão cria a consequência e quem é responsável por ela?
Que prova e recuperação são necessárias quando o resultado é incerto?

Os controlos resultam das respostas. Uma dupla aprovação pode justificar-se perante um risco e ser desnecessária noutro contexto. Uma assinatura pode provar quem assinou sem provar que o conteúdo está correcto. Uma repetição automática pode ser segura quando o serviço externo impede duplicados e perigosa quando não o faz. Guardar todas as versões pode ajudar numa auditoria e, ao mesmo tempo, contrariar uma obrigação legítima de eliminação.

O controlo não define a arquitectura. A arquitectura explica por que razão o controlo existe e onde deixa de ser útil.

A mudança profissional

As versões anteriores do meu trabalho tornavam-se frequentemente mais elaboradas à medida que a incerteza aumentava. Mais estados, mais verificações e mais componentes faziam o desenho parecer mais seguro.

Este caso alterou esse instinto. Quando uma assunção não pode ser verificada, acrescentar mecanismos à sua volta não a torna verdadeira. Uma fronteira menor pode ser o desenho mais responsável.

É esta a evolução que interessa mostrar: não uma sequência de funcionalidades entregues, mas uma mudança na forma como se distribui responsabilidade. A informação tem de permanecer compreensível. As decisões precisam de responsáveis. As consequências devem ser observáveis. A incerteza deve parar o sistema no ponto certo.

A maturidade arquitectural não se vê no número de caixas de um diagrama. Vê-se na precisão das suas fronteiras.

Fontes

TOConline, Documentos de Venda — API actual — https://api-docs.toconline.pt/apis/vendas/documentos-de-venda (consultado em 14 de Setembro de 2026).
TOConline, Documentos de Venda — Versões Anteriores — https://api-docs.toconline.pt/apis/versoes-anteriores/vendas/documentos-de-venda (consultado em 14 de Setembro de 2026).
ISO, ISO 15489-1:2016 — Records management: Concepts and principles — https://www.iso.org/standard/62542.html (versão actual confirmada pela ISO em 2021).
W3C, PROV-O: The PROV Ontology — https://www.w3.org/TR/prov-o/ (Recomendação W3C, 2013).
Object Management Group, Business Process Model and Notation 2.0.2 — https://www.omg.org/spec/BPMN/2.0.2/PDF (2014).
IETF, RFC 9110 — HTTP Semantics, §9.2.2 Idempotent Methods — https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 (2022).
União Europeia, Regulamento (UE) 2016/679 — RGPD, artigo 5.º(1)(e) — https://eur-lex.europa.eu/eli/reg/2016/679/oj.