在我用javascript(Node.js(编写的DDD应用程序中，我偶然发现了授权通用子域的实现。我检查了 RBAC/ACL 授权模型如何实现这一点，但它们似乎没有我需要的每个实例权限。
据我了解，RBAC 具有基于角色的授权。为用户分配角色。角色是分层的，并继承权限。角色可以具有多个权限。权限允许对资源执行命令。
但是，根据 RBAC 的定义，资源是通用的，如"帖子"、"评论"、"书籍"等。它们不是特定于实例的(如 Post(id：9283984((。例如，无法在 RBAC 中定义只有创建帖子的用户才能编辑它。似乎不可能在给定的"帖子(id：2398493("上将角色"管理员"分配给"用户(id：(8290321(">
定义有权执行命令的角色变得更加复杂，这些命令可以修改其他人在特定资源上的角色。
我的申请要求是：
发出 CreateLedger 命令的User将自动指定为此Ledger的Admin。他只能将其他人分配为他所Admin的账本的Managers或Collaborators或Viewers。他也可以撤销这些角色。 Managers可以管理Ledger的Accounts。 允许Collaborators在此Ledger上编辑Transactions，并且Viewers只能查看数据(只读(。Admin可以将他Admin的书籍的Admin角色分配给另一个User。
我最初的想法是，为了使用户能够管理用户在资源上的角色，需要在
user(id:X) -> role(name:Z) -> permissions -> resource(id:Y) -> commands
但在 RBAC 中只能分配
user(id:X) -> role(name:Z) -> permissions -> resource(name:"Ledger") -> commands
然后，为了克服 RBAC 的这个限制，我想用它们的 id 命名资源，比如
user(id:X) -> role(name:Z) -> permissions -> resource(name:"Ledger:39823847") -> commands
但这似乎是错误的。我还没有看到任何 RBAC 使用资源名称作为实际实例映射的示例。
我用错了锤子？我看错了？是否有其他访问控制模型更适合此任务？或者这是要走的路？如果有人能指出我正确的方向，我将不胜感激。
谢谢你的帮助
授权作为通用子域
如果要将授权建模为通用子域，则确实使用了错误的锤子。查看基于声明的授权。使用声明，您可以定义类似 modify-post:2937472 的声明。或者，当然，您可以进一步抽象这些信息。
使用此方法，通用授权子域提供了一个"容器"，其他子域在其中存储关联。因此，这种方法需要仔细集成子域，以便将事物保留在它们所属的位置。
授权作为支持子域
注意：如果你通过仔细的分析和设计得出结论，授权需要是一个通用的子域，那么以下内容不是你想要的。无论如何，我都会将其添加到我的答案中，因为对于不需要单独授权子域的项目来说，它可以是一个可行的解决方案。所以它来了：
一种根本不同的方法是将授权设计为依赖于核心子域的支持子域。有了这个，您可以使用核心模型来定义访问权限，这使得它更简单、更容易理解。
例如，博客系统的授权机制可以使用核心域中的作者、帖子、版主等概念。如果您有复杂的授权要求，这是一个巨大的胜利。
与通用子域方法相比，明显的权衡是授权不是通用的，而是绑定到特定的子域。对于特定项目，这可能是可以接受的，也可能是不可接受的，但对于不需要单独的、可重用的授权机制的小型系统来说，这是一种实用的方法。