6

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

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

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

4

1 回答 1

36

首先，我不禁觉得您误解了有界上下文的概念。您描述为 BC 的我将描述为实体。在我看来，有界上下文可以为使用通用语言定义的实体赋予给定上下文的不同目的。

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

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

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

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

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

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

虽然关于聚合设计的主题，但我不能推荐这些文章。

于 2012-07-05T12:24:34.963 回答