Domain driven design 有界上下文与聚合根

我们正在尝试使用DDD原则对基于RBAC的用户维护系统进行建模。我们确定了以下实体：

Authorization is an Aggregate Root with the following:
    User   (an entity object)
    List<Authority>    (list of value objects)

Authority contains the following value objects:
    AuthorityType (base class of classes Role and Permission)
    effectiveDate

Role contains a List<Permission>
Permission has code and description attributes

授权是具有以下内容的聚合根：
用户（实体对象）
列表（值对象列表）
权限包含以下值对象：
AuthorityType（类角色和权限的基类）
生效日期
角色包含一个列表
权限具有代码和描述属性

在典型场景中，授权肯定是聚合根，因为用户维护中的一切都围绕着这一点（例如，我可以向用户授予一个或多个权限，即角色或权限）

---

我的问题是：角色和权限如何？它们是否也在各自独立的上下文中聚合根？（即，我有三个上下文：授权、角色、权限）。虽然可以在一个上下文中组合所有内容，但角色是否太重，因为它将作为授权“对象图”的一部分加载？

首先，我忍不住觉得您误解了有界上下文的概念。你们所描述的BC，我将其描述为实体。在我看来，有界语境是为了给泛在语言中定义的实体赋予特定语境的不同目的

例如，在医院领域中，在门诊部接受治疗的患者可能有一个转诊名单，以及BookAppointment（）等方法。然而，患者被视为住院患者，将拥有一个病房属性和方法，如TransferToTheatre（）。有鉴于此，患者存在于两个有限的环境中：门诊患者和住院患者。在保险领域，销售团队制定了一份保单，该保单具有一定程度的相关风险和成本。但如果它到达索赔部门，这些信息对他们来说毫无意义。他们只需要验证保单是否对索赔有效。所以这里有两种情况：销售和索赔

第二，当您尝试实现DDD时，您是否只是以RBAC为例？我之所以提出这个问题，是因为DDD旨在帮助解决复杂的业务问题，即需要计算的地方（如保单风险）。在我看来，RBAC是一个相当简单的基础设施服务，它与实际的域逻辑无关，因此不保证严格的DDD实现。DDD的投资成本很高，你不应该仅仅为了它而采用它；这就是为什么有界上下文很重要的原因——只有在合理的情况下，才使用DDD对上下文进行建模

无论如何，冒着这个答案听起来像“学术”的风险，我现在将尝试回答您的问题，假设您仍然希望将其建模为DDD：

对我来说，这一切都符合一个上下文（称为“安全”或其他）

一般经验法则是，将所有需要独立事务的内容都作为一个集合，因此：

假设系统允许向授权对象添加权限，则将授权作为一个聚合。（尽管可能有人主张放弃授权并简单地将用户作为具有权限列表的聚合根目录）

权限在授权聚合之外没有任何意义，仅在添加一个权限时创建，因此这些权限仍然作为实体

假设系统允许将权限添加到角色，角色成为聚合根

假设权限无法创建/删除-即它们由系统本身定义，因此它们是简单的值对象

---

关于骨料设计的主题，我不能仅推荐这些。

再次感谢David。您的语句“有界上下文用于为泛在语言中定义的实体提供与给定上下文不同的用途”让我明白了这一点。我想一开始让我感到困惑的是必须通过AR才能访问其中一个EO/VO。这是令人困惑的，因为正如您所提到的，角色也是授权AR中引用的AR。我们将进行RBAC练习，以了解使用DDD的诀窍。我认为我们正在研究的其他上下文适合应用DDD。没问题。我给出的另一条建议是：让聚合通过引用其ID引用其他聚合，而不是聚合本身。如果你读了我建议的文章，它解释了原因。我喜欢这个例子，让我清楚地理解上下文