有界上下文和聚合根

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是我所描述的实体。在我看来，有限的语境有助于使普遍存在的语言中定义的实体在给定的语境中具有不同的目的。

例如，在医院领域，在门诊部门接受治疗的患者可能有一个推荐列表，以及 BookAppointment（）等方法。然而，患者被视为住院患者，将具有 Ward 属性和方法，例如 TransferToTheatre（）。鉴于此，患者存在两种有限的背景：门诊患者和患者。住院病人。在保险领域，销售团队制定了一个政策，其风险程度与成本相关。但如果它到达索赔部门，那么这些信息对他们来说毫无意义。他们只需要验证该政策是否对索赔有效。所以这里有两种情况：Sales＆amp;权利要求书

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

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

对我而言，这一切都适合一种情境（称为“安全”或其他）

作为通用经验法则，将所有内容都设为需要独立交易的聚合，因此：

1. 假设系统允许将权限添加到授权对象，请将授权作为聚合。 （尽管可能存在抛弃授权并简单地将用户作为权限列表的聚合根目录）的论据
2. 权限在授权聚合之外没有任何意义，只有在添加时才会创建，因此这些仍然是实体。
3. 假设系统允许权限添加到角色，角色将成为聚合根。
4. 假设无法创建/删除权限 - 即它们是由系统本身定义的，因此这些是简单的值对象。

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