如何在多租户产品中构建团队模型

一旦确定了租户边界，下一个问题就是边界内部包含什么内容。以下是我如何对团队进行建模，使其角色、邀请以及生命周期状态符合真实的组织行为。

这是系列文章构建符合现实世界的多租户系统的第二部分。
第一部分：设计兼具所有权和团队访问权限的多租户后端

“用户列表”与真实团队之间的差距

在第一部分中，我讨论了为什么应将租户建模为具有边界的组织，而不仅仅是带有 tenantId 列的数据桶。

一旦确立了这种边界，一个新的问题便立即浮现：

谁在组织内部，他们被允许做什么？

天真的答案是“只需存储用户标识并赋予他们一个角色”。

这个答案很快就会站不住脚，因为组织内的真实团队不仅仅是一个用户列表。

它是一组具有状态的关系：

一旦你认识到这一点，“存储带有角色的用户标识”就成为一个不足的模型。

以下是真实的团队模型需要做的事情。

这是我必须内化的第一件事。

User（用户）是系统中的身份标识。

TeamMember（团队成员）（或 StoreStaff [门店员工]、WorkspaceMember [工作区成员]、ClinicStaff [诊所员工]——无论你的领域如何称呼它）是用户与组织之间的关系。

这是两件不同的事情，混淆它们会导致问题。

当你混淆它们时，最终会得到如下所示的模式：

interface User {
  id: string;
  email: string;
  organizationId: string;   // ← 隐式成员资格
  role: string;             // ← 隐式的、未限定范围的角色
}

该设计存在四个问题：

用户只能属于一个组织。
角色是全局的，而非限定于特定组织。
成员资格本身没有生命周期。
从
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。