domain-driven-design - 有界上下文和聚合根

Question

我们正在尝试使用 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

在典型的场景中，授权绝对是聚合根，因为用户维护中的一切都围绕着它(例如，我可以授予用户一个或多个权限，即角色或权限)

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

Answer 1

首先，我不禁感到您误解了有界上下文的概念。您所描述的 BC 我将描述为实体。在我看来，有界上下文可以为在通用语言中定义的实体提供针对给定上下文的不同目的。

例如，在医院域中，在门诊部接受治疗的 患者 可能具有 转诊列表 和 BookAppointment() 等方法。然而，一个 患者 被视为住院患者，将具有 Ward 属性和方法，例如 TransferToTheatre()。鉴于此，患者存在于两个有界上下文中:门诊患者和住院患者。在保险领域，销售团队将 保单 放在一起，该保单具有一定程度的风险和成本。但如果它到达 claim 部门，这些信息对他们来说毫无意义。他们只需要验证保单是否对 claim 有效。所以这里有两个上下文:销售和 claim

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

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

对我来说，这一切都适合一种情况(称为“安全”或其他东西)

作为一般的经验法则，将所有需要独立事务的东西都聚合起来，所以:

假设系统允许将 Authorization 添加到 Authorization 对象，使 对象聚合为 。 (尽管可能存在放弃 授权 并简单地使 用户 成为具有 权限列表的聚合根 Authorities 50x704 _607920 的争论)

Authorities 在 Authorization 聚合之外没有任何意义，并且仅在添加一个时创建，因此这些仍然作为实体。

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

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

虽然在聚合设计的主题上，我不能推荐这些 articles 足够。