Conceito e mecanismo
Começa pelo processo e pelos seus limites: quem cria trabalho, que estados existem, quem decide e que evidência permite encerrar. Uma aplicação de exceções de reconciliação pode organizar registos, atribuições e aprovações sem executar o cálculo financeiro de baixa latência. Confirma requisitos de volume, latência, integração e licenciamento antes de escolher onde cada responsabilidade vive. No modelo, separa a entidade de negócio da sua apresentação. Uma exceção pode referenciar um fundo e conter várias tentativas de resolução; copiar o nome do fundo em cada registo cria divergências quando o nome muda. Usa referências e relações com cardinalidade explícita. A identidade técnica deve manter-se estável mesmo quando a designação comercial muda.
Aplicação guiada
Antes de criar tabelas, desenha alguns registos fictícios e percorre uma alteração de nome, uma transferência de equipa e a reabertura de uma exceção. Verifica quais dados são próprios e quais são partilhados. Estender uma tabela pode reutilizar comportamento e campos, mas também traz herança que deve ser analisada; não escolhas a tabela base apenas para poupar cliques. A documentação distingue nomes internos de labels: scope e nome interno da tabela não são renomeados como uma etiqueta de apresentação. Regista essa escolha cedo. Constrói um protótipo em ambiente de desenvolvimento com dados sintéticos e valida relações e acesso. O resultado deve permitir explicar o estado de cada exceção e a origem das decisões sem duplicar o sistema financeiro responsável pelos valores.
Um fundo muda de nome; a referência mantém a relação sem reconstruir todas as exceções.
Armadilhas comuns
Confundir label com identidade; estender sem avaliar herança; assumir adequação sem requisitos.
Tópicos relacionados: Scope, módulos e dependências · Formulários e lógica cliente/servidor · Segurança e contratos de acesso
Modela entidades, relações e responsabilidades antes dos formulários.
Referência: Define and build the data model · CAD blueprint January 2026