Ideia principal

Os dois recortes técnicos de um software não têm o mesmo valor para o negócio, e confundi-los custa um projeto inteiro.

Os módulos — faturamento, compras, permissões de acesso — foram traçados por desenvolvedores, mas correspondem, grosso modo, a partes do negócio. É uma descrição parcial, de graça, validada por anos de uso: um ponto de partida que seria um erro recusar só porque vem do código.

As tabelas, não. Uma tabela não é um objeto do negócio: muitas só servem para ligar duas outras tabelas, guardar um rastro técnico, armazenar tokens de login ou resultados temporários. Fazer uma ficha por tabela é copiar a estrutura técnica tal como está e descrever no mesmo nível o que importa e o que não significa nada para quem fala do produto.

O terceiro recorte possível — o das pastas, percorridas em ordem — não tem nenhuma relação com a importância para o negócio e produz uma massa de fichas sem saber quais importam.

Camada trazida por "Ontology-Driven Design: e se a ontologia virasse a rede de segurança do código gerado por IA?" (2026-10-29). A mesma distância vale para as outras unidades do código. Uma classe não é necessariamente um conceito de negócio, um pacote novo pode ser só uma reorganização técnica, uma função pode implementar uma regra sem ser um conceito. Uma ontologia que acompanha o código precisa, portanto, continuar independente da arquitetura dele — hexagonal, Domain-Driven Design ou código bagunçado: o modelo representa o domínio, não a estrutura técnica.

Por que isso importa

Isso resolve a primeira decisão de um trabalho de descrição: por onde avançar. Apoiar-se nos módulos custa zero e dá uma ordem já validada; apoiar-se nas tabelas obriga a refazer, à mão e objeto por objeto, a triagem que o banco de dados não faz.

Isso vale de forma mais ampla: um recorte herdado não deve ser adotado nem rejeitado em bloco; ele é julgado pelo que custou para ser produzido e pelo que ele codifica do negócio.

Nuances e limites

A aproximação dos módulos continua sendo uma aproximação: objetos expostos para fora podem estar espalhados por vários módulos e, por isso, ficam invisíveis enquanto você avança parte por parte. É por isso que o avanço por módulos precisa ser complementado por outros ângulos de enumeração.

E as tabelas continuam tendo valor, mas como ângulo de verificação — elas fazem aparecer objetos armazenados que nenhuma descrição menciona —, nunca como plano de trabalho.

Questões em aberto

• Num software cujos módulos não correspondem mais ao negócio porque a organização mudou, que recorte herdado assume o lugar deles?