Uma despesa compartilhada pode ter três pessoas diferentes: quem registrou, quem pagou e quem pode consultar. Um único campo user_id perde essas distinções. Em um cenário como o de um app de finanças familiares, separar os papéis permite responder quanto cada membro pagou sem perder a autoria do lançamento.

Onde fica a autorização

O adaptador HTTP extrai a identidade autenticada e valida o formato da requisição. O caso de uso recebe essa identidade e verifica o vínculo com a família antes de gravar. O domínio valida invariantes da despesa, como valor positivo para um lançamento do tipo gasto. O adaptador PostgreSQL executa as operações de persistência por meio das interfaces usadas pela aplicação.

Uma importação em lote pode acionar o mesmo caso de uso. Se a autorização estivesse apenas no handler HTTP, o importador teria de reproduzir a regra por conta própria. Colocá-la na aplicação permite testar os dois caminhos contra a mesma decisão de acesso.

O teste que revela a fronteira

Monte uma família existente e um usuário que conhece o ID dela, mas não tem vínculo ativo. Envie uma despesa válida pelo caso de uso. O resultado esperado é um erro de autorização e zero gravações. Depois, repita com um membro autorizado e um pagador diferente. A despesa deve registrar os dois papéis.

Se suspender um membro pode coincidir com uma gravação, decida quando a mudança passa a valer e cubra a corrida em um teste real de banco. A escolha de isolamento ou bloqueio depende dessa regra.

Artigo original sobre arquitetura hexagonal, de Alistair Cockburn · Idempotência em APIs financeiras