domain-driven-design - 解决对实体内部聚合 (DDD) 的外部引用的明显需求

Question

我正在尝试遵循 DDD 原则来创建一个模型来确定身份是否有权访问属于资源的操作。

资源(例如网络服务)是包含多个操作(例如方法)的东西，可以访问也可以不访问。身份是想要访问资源上的一个或多个操作的东西。比如有人在调用webservice方法时使用了api-key，需要判断是否允许访问。

目前看来，Identity和Resource是聚合根，Action是属于Resource的实体。一个 Action 独立存在似乎没有意义；它永远属于一个资源。身份需要知道它有权访问哪些资源操作。这似乎暗示了以下模型。

然而，据我了解，这违反了聚合外的东西不能引用聚合内的实体的原则。它必须通过根。然后我在想，如果 Action 是聚合根而 Resource 是一个实体呢？但这对我来说似乎不太合逻辑。我也一直在考虑将 Resource 和 Action 合并到一个实体中，这将成为一个聚合根，但这对我来说也是错误的。

因此，这让我对如何使用 DDD 原则正确建模感到困惑。有人知道如何对此建模吗？

更新:我尝试创建的模型是用于定义允许身份访问哪些资源操作的身份模型。它不是实际实现资源和操作的模型。

更新 2 - 不变量:所有对象的 Id 都是出生时给定的，是唯一的，不会改变。身份的 ApiKey 在所有身份中必须是唯一的。Action 的名称在聚合中必须是唯一的，但是两个不同的资源可以具有相同名称的 Action，例如资源“R1”可以有一个 Action “A1”，资源“R2”也可以有一个 Action “A1”，但这两个“A1”不一样。

Answer 1

查询还是写操作？

就聚合和实体而言，域模型在 DDD 中的目的是为了简化不变量的表达和实现——因为写入操作应用于模型。

正如@VoiceOfUnreason 的回答中提到的，“这个用户可以对资源 R 执行操作 A”这个问题是一个不一定需要流经域模型的问题 - 它可以通过针对 pre 的查询来回答- 投影只读模型，或针对构成写入模型持久性的表的标准 SQL 查询(取决于您的需要)。

拆分上下文以简化不变量

但是，您的问题虽然主要是关于如何识别身份是否被允许执行某项操作，但隐含地寻求一种更简单的模型来更新资源、操作和权限。所以要探索这个想法......隐式有两种类型的写操作:

1. 定义可用资源和操作
2. 定义允许特定身份执行的资源操作组合

如果将这两种类型的操作拆分到不同的限界上下文中，它们的模型可能会得到简化。

首先，您将像您所做的那样建模，一个以 Resource 作为聚合根并将 Action 作为包含实体的聚合。这允许强制执行操作名称在资源中必须唯一的不变性。

随着在此上下文中进行更改，您发布事件，例如ActionAddedToResource，ActionRemovedFromResource。

在第二个上下文中，您将拥有三个聚合:

• 身份
• 资源行动
  • 属性:Id、ResourceId、ResourceName、ActionId、ActionName
• 许可

ResourceAction 实例将根据从第一个上下文发布的事件进行更新 - 在 ActionAddedToResource 上创建，在 ActionRemovedFromResource 上删除。如果资源没有任何操作，则根本没有 ResourceAction。

权限将包含两个身份引用 - IdentityId 和 ResourceActionId

这种方式在执行操作“允许此用户对此资源执行此操作”时，操作只是创建一个新的权限实例 - 减少影响身份聚合的一致性边界的操作集 - 假设没有需要在身份聚合中强制执行“许可”概念的不变量？

这也简化了查询方面的事情，因为您只需要搜索具有匹配的 identityId、resourceName 和 actionName 的权限条目加入 Permissions 到 ResourceActions 之后。

责任层

战略设计部分中的 DDD 手册指的是根据责任层组织您的上下文。用书中的术语来说，上述建议是基于“能力”责任层(定义资源和操作)和“操作”责任层(定义身份权限和检查身份权限)的想法。