A próxima descoberta veio de um lugar meio banal.

Cadastro.

Eu estava olhando estruturas diferentes, sistemas diferentes, áreas diferentes, e comecei a notar uma coisa que parecia pequena demais para importar.

Só que importava muito.

A mesma pessoa aparecia várias vezes.

• No CRM, ela era contato.
• No financeiro, cliente.
• No projeto, responsável.
• No atendimento, solicitante.
• No marketing, lead.
• No contrato, representante.
• No calendário, participante.
• No sistema, usuário.

E eu comecei a pensar:

Quantas pessoas existem aqui de verdade?

Uma.

Só uma.

O resto eram papéis.

01A duplicação parecia normal porque os sistemas foram construídos assim

Cada módulo queria ter seu próprio cadastro.

Fazia sentido localmente.

• O Comercial precisava de contatos.
• O Financeiro precisava de clientes.
• O RH precisava de colaboradores.
• Projetos precisava de responsáveis.
• Suporte precisava de solicitantes.

Só que, quando você olha a empresa como um todo, acontece uma coisa estranha.

Nós pegamos uma realidade única e criamos várias cópias dela para que cada sistema pudesse trabalhar.

Depois precisamos sincronizar as cópias.

E depois criamos regras para decidir qual cópia está certa.

É quase engraçado.

Primeiro duplicamos.

Depois gastamos energia tentando desfazer o efeito da duplicação.

02Eu comecei pela pessoa porque era o exemplo mais fácil

Imagine uma pessoa chamada Marina.

Marina trabalha na Empresa Alfa. Ela participa de um projeto. Também é responsável por uma aprovação. Recebe uma proposta. Depois vira cliente. Mais tarde participa de um evento.

Nada disso cria novas Marinas.

Mas um sistema tradicional pode terminar com algo parecido com:

Cinco registros.

Uma pessoa.

E aí vem a pergunta:

Qual deles é a Marina? Todos? Nenhum? O mais atualizado? O que tem o e-mail certo?

03Foi aqui que comecei a separar identidade de contexto

Talvez uma coisa precise ter uma identidade própria.

E o que muda ao redor dela são as relações.

Marina continua sendo Marina.

A entidade não muda.

O papel muda. A relação muda. O contexto muda.

Essa diferença começou a abrir uma porta enorme.

04E não era só pessoa

A mesma lógica aparecia em quase tudo.

Uma empresa podia ser:

• cliente;
• fornecedora;
• parceira;
• concorrente;
• investidora;
• empresa do grupo.

Mas ela continuava sendo a mesma empresa.

Um documento podia aparecer:

• no projeto;
• no jurídico;
• no administrativo;
• na reunião;
• numa decisão.

Mas continuava sendo o mesmo documento.

Um produto podia aparecer:

• no catálogo;
• na campanha;
• na proposta;
• na venda;
• no financeiro;
• no atendimento.

Mas era o mesmo produto.

Um projeto podia aparecer:

• em estratégia;
• financeiro;
• operação;
• RH;
• cliente.

Mas era o mesmo projeto.

Eu estava começando a enxergar um padrão.

05Talvez o papel não devesse estar dentro da identidade

Essa ideia parece técnica, mas ela é quase filosófica.

Uma pessoa é uma coisa.

Ela está em determinadas relações.

Ela assume determinados papéis.

Mas o papel não define sua existência inteira.

Isso começou a ficar especialmente importante quando pensei em empresas pequenas.

Uma pessoa pode fazer:

• Comercial.
• Marketing.
• Financeiro.
• Atendimento.

Isso significa que existem quatro pessoas?

Claro que não.

Significa que uma mesma pessoa exerce quatro funções.

E talvez nem existam quatro departamentos formais.

Se eu misturasse pessoa, função e departamento, o sistema começaria errado.

Essa ideia depois ficaria muito clara para mim:

Na época eu ainda não tinha transformado isso em regra.

Mas já estava ali.

06O mesmo problema aparecia com cliente

Esse foi outro ponto importante.

Quando alguém entra no funil, chamamos de lead. Depois oportunidade. Depois proposta. Depois venda. Depois cliente.

É tentador modelar assim:

como se fossem registros independentes.

Só que talvez não sejam coisas diferentes.

Talvez seja a mesma pessoa ou empresa atravessando estados diferentes de uma relação comercial.

Isso muda bastante.

Porque você não precisa criar um novo cliente quando a venda fecha.

Você só precisa registrar:

esta relação mudou de estado.

A pessoa continua sendo a mesma. A empresa continua sendo a mesma. O histórico continua junto. As conversas anteriores continuam relevantes. As objeções continuam relevantes. A proposta continua relevante.

O contexto não é perdido na passagem.

07Foi aí que comecei a desconfiar das tabelas

Não porque tabelas sejam ruins.

Tabelas são ótimas.

Continuo usando.

O problema era outro.

Eu estava deixando a estrutura da tabela definir aquilo que existia.

Se eu tinha uma tabela chamada clientes, então cliente parecia ser uma coisa. Se tinha fornecedores, fornecedor parecia outra. Se tinha colaboradores, outra.

Mas talvez essas tabelas fossem apenas views sobre uma identidade compartilhada.

Foi uma mudança pequena na pergunta:

Em vez de:

Em qual tabela isso entra?

comecei a pensar:

O que isso é?

E depois:

Como isso se relaciona com o restante?

Essa segunda pergunta começou a ficar cada vez mais importante.

08A realidade não sabe que existe menu

Uma empresa não sabe que no software existem botões chamados:

• Financeiro.
• Comercial.
• Projetos.
• Marketing.
• RH.

Na realidade, tudo se mistura.

Uma venda envolve:

• cliente;
• produto;
• pessoa;
• preço;
• contrato;
• financeiro;
• projeto;
• entrega.

Um problema de cliente pode envolver:

• suporte;
• produto;
• financeiro;
• comercial;
• projeto;
• documento.

Uma contratação pode impactar:

• RH;
• financeiro;
• operação;
• projeto;
• estratégia.

A realidade atravessa módulos o tempo inteiro.

Então talvez o sistema precisasse permitir o mesmo.

09Eu comecei a imaginar a entidade como um núcleo

Ainda não era o CORE.

Era mais uma imagem mental.

Alguma coisa no centro.

E ao redor dela, relações.

Uma pessoa no centro. Ao redor:

• empresa;
• projeto;
• cargo;
• cliente;
• documento;
• reunião.

Uma empresa no centro. Ao redor:

• pessoas;
• clientes;
• produtos;
• projetos;
• decisões;
• documentos;
• departamentos.

Quanto mais eu imaginava isso, menos sentido fazia continuar duplicando registros.

10Mas aí apareceu uma pergunta nova

Se tudo fosse centralizado demais, eu poderia cair no problema oposto.

Um banco gigantesco onde tudo era "coisa".

Isso também seria inútil.

Uma pessoa precisa ser diferente de um projeto. Um projeto precisa ser diferente de um documento. Uma decisão precisa ter comportamento diferente de uma empresa.

Então eu não queria apagar as diferenças.

Eu queria encontrar aquilo que elas tinham em comum.

Alguma estrutura básica.

• Identidade.
• Propriedades.
• Relações.
• Histórico.
• Contexto.

Eu ainda não tinha os nomes finais.

Mas já estava procurando esse DNA comum.

11Foi aí que a palavra entidade começou a fazer sentido

Eu já conhecia o termo tecnicamente.

Claro.

Banco de dados usa entidade. Modelagem usa entidade. Sistemas usam entidade.

Mas eu comecei a usar a palavra de outra maneira dentro do raciocínio.

Uma entidade seria:

alguma coisa que importa o suficiente para possuir identidade própria dentro do sistema.

• Pessoa.
• Empresa.
• Projeto.
• Produto.
• Documento.
• Decisão.
• Objetivo.
• KPI.
• Agente.
• Workflow.

E depois poderíamos perguntar:

• Quem é?
• O que sabemos?
• Com o que está relacionada?
• O que aconteceu com ela?
• Quem pode vê-la?
• Qual é seu estado?

12Essa ideia resolveu um problema e criou dez outros

O que, sinceramente, virou um padrão nesse projeto.

Toda vez que eu encontrava uma ideia boa, ela não encerrava a discussão.

Ela abria outra porta.

Se tudo pode ser entidade:

• Como uma entidade se relaciona com outra?
• Relação também precisa de propriedades?
• Como representamos tempo?
• Como representamos mudança?
• Como evitamos criar entidade para qualquer coisa?
• Como uma IA entende essas relações?
• Como uma tela mostra isso sem virar um caos?
• Como um módulo trabalha com a mesma entidade sem duplicá-la?

E a maior:

O que faz uma entidade significar alguma coisa?

Porque saber que Marina existe ainda é pouco.

Saber que existe uma Empresa Alfa também.

O significado começa a aparecer quando descobrimos:

• Marina trabalha na Empresa Alfa.
• Marina lidera o Projeto Atlas.
• O Projeto Atlas busca o Objetivo X.
• O Objetivo X é medido pelo KPI Y.

Agora já não temos apenas objetos.

Temos contexto.

E foi aí que eu percebi que uma entidade sozinha não explica quase nada.

---

Esta série acompanha as perguntas, erros e descobertas que deram origem à archē.