有界上下文和聚合根

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

在典型情况下，授权绝对是聚合根，因为用户维护中的所有内容都围绕着它（例如，我可以授予用户一个或多个权限，即角色或权限）

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

Answer 1

首先，我不禁觉得您误解了有界上下文的概念。你所描述的 BC 我将描述为实体。在我看来，有界上下文有助于为使用通用语言定义的实体提供针对给定上下文的不同用途。

例如，在医院域中，在门诊部接受治疗的 Patient 可能有一个 Referrals 列表，以及诸如 BookAppointment() 之类的方法。但是，被视为住院患者的 Patient 将具有 Ward 属性和方法，例如 TransferToTheatre()。鉴于此，患者存在两种有限的环境：门诊患者和住院患者。在保险领域，销售团队制定了一个政策，该政策具有一定程度的相关风险并因此产生成本。但如果它到达索赔部门，这些信息对他们来说毫无意义。他们只需要验证保单是否对索赔有效。所以这里有两个上下文：销售和索赔

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

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

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

作为一般的经验法则，将所有东西都设为需要独立事务的聚合，因此：

1. 假设系统允许将 Authorities 添加到 Authorization 对象，则将 Authorization 设为聚合。 （尽管可能有人认为放弃 Authorization 并简单地将 User 设为具有 Authorities 列表的聚合根）
2. Authorities 在 Authorization 聚合之外没有任何意义，并且仅在添加一个时创建，因此它们仍然作为实体。
3. 假设系统允许将 Permissions 添加到 Role，Role 将成为聚合根。
4. 假设 权限 无法创建/删除 - 即它们是由系统本身定义的，因此这些是简单的值对象。

关于聚合设计的主题，我不能推荐这些articles。