Propriedade de recursos em um SaaS: pessoa, organização ou espaço de trabalho

Em um SaaS no qual uma pessoa pode trabalhar em várias organizações ou espaços, «quem criou este recurso?» não responde necessariamente a «a quem ele pertence?». Essa diferença afeta quem pode visualizá-lo, modificá-lo, transferi-lo ou mantê-lo quando alguém sai de uma equipe. Resolver isso tarde costuma deixar regras dispersas em consultas, controladores e tarefas em segundo plano.

A propriedade de recursos em SaaS multiusuário é uma decisão de domínio: determina qual entidade tem a relação principal com um recurso e quais consequências essa relação tem. Não é sinônimo de autenticação, associação nem permissões. Modelá-la explicitamente permite que produto, dados e código compartilhem uma regra coerente.

Identidade, associação e propriedade são relações distintas

Um usuário representa uma identidade que pode fazer login. A associação expressa que essa identidade participa de uma organização ou espaço de trabalho, possivelmente com um papel ou um estado. A propriedade indica qual entidade responde por um recurso segundo as regras do produto. Uma pessoa pode participar de vários espaços e, ao mesmo tempo, criar um documento que pertence a um deles.

Também convém separar a autoria. O campo created_by pode preservar quem realizou a ação inicial, mas não deve, por si só, determinar a propriedade. Se quem criou o registro deixar a organização, o recurso ainda poderá pertencer a ela. Por outro lado, uma pessoa pode adquirir um recurso criado originalmente por outra.

É útil documentar as respostas a três perguntas: quem é o proprietário, quem pode operar sobre o recurso e quem realizou cada ação relevante. Se o mesmo campo ou relação pretende responder a todas elas, provavelmente o modelo está misturando conceitos.

Escolher entre propriedade pessoal, organizacional ou compartilhada

• Pessoal: o recurso pertence a um usuário. Faz sentido quando seu ciclo de vida acompanha essa pessoa, e não uma equipe, como no caso de uma preferência privada. É preciso decidir o que acontece se a conta for desativada ou excluída.
• Organizacional: pertence a uma organização ou espaço de trabalho. É adequada quando o recurso deve continuar disponível para a equipe mesmo que seus integrantes mudem. A associação do usuário habilita o acesso, mas não o torna proprietário individual.
• Compartilhada: várias entidades podem ter uma relação de titularidade ou responsabilidade. Use-a apenas se o domínio realmente precisar de copropriedade. Se o requisito for permitir que várias pessoas consultem ou editem, normalmente isso é acesso por meio de associações ou permissões, não vários proprietários.

A decisão deve acompanhar o ciclo de vida do recurso e as regras de negócio, não uma preferência por simplificar uma tabela. Pergunte quem pode mantê-lo, decidir sua exclusão e responder por ele quando a equipe mudar. Diferencie também «espaço de trabalho» de «organização»: se o primeiro for uma subdivisão real, com ciclo de vida e limites próprios, pode ser o proprietário adequado; se for apenas uma visualização ou contexto de navegação, talvez não.

Representar o domínio sem inferir quem é o proprietário

Em um modelo simples, uma tabela de recursos pode ter um proprietário explícito, por exemplo owner_type e owner_id, ou referências separadas como user_id e organization_id. A primeira opção pode facilitar o suporte a vários tipos de proprietário, mas exige validar referências e considerar as limitações de integridade referencial das relações polimórficas. As referências separadas tornam os vínculos mais explícitos, embora seja necessário impedir combinações inválidas.

Outra alternativa é uma entidade comum, por exemplo workspace, se o domínio realmente representar contas pessoais e equipes sob ela. Não a introduza apenas para ocultar diferenças: ela deve ter significado e regras estáveis. Em qualquer projeto, estabeleça restrições que impeçam que um recurso seja associado simultaneamente a proprietários incompatíveis ou a nenhum proprietário, quando a propriedade for obrigatória.

Modele as associações separadamente, por exemplo, com uma relação entre usuário e organização que inclua estado e papel. O contexto ativo da interface pode indicar onde a pessoa está trabalhando no momento, mas não é uma autoridade suficiente: deve ser validado em cada operação. Da mesma forma, o proprietário não deve ser calculado como «quem criou o recurso» nem como «a organização selecionada atualmente».

Aplicar a propriedade em leituras, gravações e processos automatizados

As consultas devem incluir o escopo de propriedade e uma verificação de acesso adequada. Não basta carregar o recurso pelo identificador e confiar que a interface oculte aqueles que não correspondem. Em uma aplicação PHP, centralize a resolução do contexto e as regras de autorização em uma camada reutilizável e evite replicar condições incompletas em cada controlador.

Nas gravações, valide o proprietário permitido e a associação vigente do usuário. Verifique também se os recursos relacionados — por exemplo, uma pasta de destino — pertencem a um escopo compatível; caso contrário, uma atualização pode criar associações cruzadas. Para operações administrativas, separe explicitamente a autorização excepcional das regras comuns e registre quem a executou e o motivo.

Filas, comandos agendados, webhooks e importações nem sempre têm um usuário interativo. Eles devem transportar um identificador de proprietário ou um contexto validado, em vez de depender de uma sessão implícita. O processo deve aplicar as mesmas regras de escopo que a aplicação web. Se operar com privilégios ampliados, limite e audite esses privilégios.

Tratar a transferência como uma operação de domínio

Alterar o proprietário não deve ser uma edição genérica de um campo. Defina pré-condições: quem pode iniciar a transferência, que relação o destinatário precisa ter com o espaço e o que fazer se houver um convite pendente ou uma conta inativa. A operação deve ser atômica quando atualizar várias relações e efeitos associados.

Determine também o que acontece com dependências, como arquivos, integrações, faturamento ou automações. Não suponha que tudo deva ser movido junto com o recurso: essa política depende do produto. Se não for possível concluir todas as alterações em uma transação, projete um processo recuperável, com estados claros e idempotência para novas tentativas.

Mantenha um registro de auditoria com o usuário responsável, o proprietário anterior, o novo proprietário, o momento e o motivo, quando aplicável. Assim, é possível distinguir quem autorizou a alteração de quem executou a ação técnica. A autoria original pode ser mantida sem alterações, mesmo que a titularidade mude.

Testar os limites que revelam erros de modelagem

Automatize testes de serviço e de integração para verificar tanto os acessos permitidos quanto os negados. Uma matriz útil inclui uma pessoa em duas organizações, recursos próprios e alheios em ambas, associações suspensas ou revogadas, transferência para um destino inelegível e acesso por identificadores conhecidos. Verifique as respostas e os efeitos nos dados; ocultar um botão não é um teste de autorização.

Teste também recursos sem proprietário válido, relações duplicadas e falhas durante uma transferência. Se o esquema exigir um proprietário, as restrições do banco de dados devem respaldar essa expectativa, e as migrações devem detectar registros históricos inconsistentes antes de adicionar as restrições. Para tarefas em segundo plano, verifique se o contexto é mantido e se uma nova tentativa não duplica as alterações.

Lista de verificação antes de ampliar o SaaS

• Está definido se cada tipo de recurso pertence a uma pessoa, organização ou espaço?
• Propriedade, autoria, associação, papel e contexto ativo são diferenciados?
• As consultas de leitura e gravação validam o proprietário e a associação atual?
• As tarefas automatizadas recebem um escopo explícito e aplicam controles equivalentes?
• A transferência tem pré-condições, efeitos definidos, auditoria e estratégia de recuperação?
• Há testes para usuários com vários espaços, baixas de associação, acessos cruzados e dados inconsistentes?

Se alguma resposta depender de convenções não documentadas, convém esclarecê-la antes de adicionar mais tipos de recursos ou fluxos de colaboração. Um modelo explícito não elimina todos os casos complexos, mas torna as decisões visíveis e permite verificá-las no esquema, nas consultas e nos testes.