O problema que o caderno físico não conseguia resolver
Na Sentric, quando uma câmera saía para instalação, o técnico anotava em um caderno. Quando voltava, outra anotação. Quando ia para manutenção, mais uma anotação — se lembrava. O resultado era previsível: câmeras sem paradeiro conhecido, técnicos ligando uns para os outros para saber “onde está a câmera X”, patrimônio parado porque ninguém sabia se o equipamento estava disponível ou em campo.
O problema fundamental não era falta de disciplina — era a ausência de um sistema que tornasse o registro da movimentação inevitável e instantâneo.
A decisão de design mais importante: append-only
A maioria dos sistemas de inventário funciona com um registro central que é atualizado destrutivamente: “câmera X agora está no cliente Y”. Isso resolve a consulta atual, mas destrói o histórico. Se a câmera sumiu, você não tem como saber quem a pegou por último.
O Inventário Sentric funciona de forma diferente: cada movimentação é um evento imutável. Quando a câmera sai para instalação, cria-se um evento SAIDA_CAMPO. Quando volta, um evento RETORNO_BASE. O estado atual da câmera é calculado a partir da sequência de eventos — não armazenado diretamente. Isso significa trilha de auditoria completa sem nenhum esforço adicional: ela é uma consequência estrutural do design, não uma feature separada.
DataMatrix em campo
A etiqueta física é o que ancora a identidade digital ao objeto físico. Optamos por DataMatrix em vez de QR Code por três razões:
- Densidade: armazena mais dados no mesmo espaço físico
- Robustez: leitura confiável mesmo com até 30% da etiqueta danificada
- Leitura oblíqua: funciona em ângulos que fariam um QR Code falhar
O código impresso na etiqueta inclui check digit Luhn — o mesmo algoritmo de cartões de crédito — para detectar erro de digitação antes de chegar ao banco.
packages/domain — o coração sem batimento
A decisão de isolar completamente o domínio em um package sem nenhuma dependência de I/O tem um efeito prático imediato: a state machine da câmera pode ser testada com fast-check gerando milhares de sequências de eventos aleatórias, verificando invariantes como “uma câmera nunca pode estar em dois lugares ao mesmo tempo” ou “não é possível dar baixa em uma câmera que não está na base”.
Esses testes não precisam de banco, não precisam de mock, não precisam de servidor. São funções puras — e fast-check encontra edge cases que nenhum teste escrito à mão encontraria.