有限的上下文和汇总根 [英] Bounded Contexts and Aggregate Roots

问题描述

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

We are trying to model an RBAC-based user maintenance system using DDD principles. We have identified the following entities:

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

在典型情况下，授权绝对是聚合根因为用户维护中的所有事情都围绕着这个问题（例如，我可以授予用户一个或多个既是角色又是权限的Authority-ies）

In a typical scenario, Authorization is definitely the Aggregate Root since everything in user maintenance revolves around that (e.g. I can grant a user one or more Authority-ies which is either a Role or Permission)

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

My question is : what about Role and Permission? Are they also Aggregate Roots in their own separate contexts? (i.e. I have three contexts, authorization, role, permission). While can combine all in just one context, wouldn't the Role be too heavy enough since it will be loaded as part of the Authorization "object graph"?

推荐答案

首先，我不禁感到您误解了有界上下文的概念。您所说的不列颠哥伦比亚省就是我所说的实体。在我看来，有限的上下文可以使使用通用语言定义的实体在给定的上下文中具有不同的用途。

Firstly I can't help but feel you've misunderstood the concept of a bounded context. What you've described as BC's I would describe as entities. In my mind, bounded contexts serve to give entities defined in the ubiquitous language a different purpose for a given context.

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

For example, in a hospital domain, a Patient being treated in the outpatients department might have a list of Referrals, and methods such as BookAppointment(). A Patient being treated as an Inpatient however, will have a Ward property and methods such as TransferToTheatre(). Given this, there are two bounded contexts that patients exist in: Outpatients & Inpatients. In the insurance domain, the sales team put together a Policy that has a degree of risk associated to it and therefore cost. But if it reaches the claims department, that information is meaningless to them. They only need to verify whether the policy is valid for the claim. So there is two contexts here: Sales & Claims

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

Secondly, are you just using RBAC as an example while you experiment with implementing DDD? The reason I ask is because DDD is designed to help solve complex business problems - i.e. where calculations are required (such as the risk of a policy). In my mind RBAC is a fairly simple infrastructure service that doesn't concern itself with actual domain logic and therefore doesn't warrant a strict DDD implementation. DDD is expensive to invest in, and you shouldn't adopt it just for the sake of it; this is why bounded contexts are important - only model the context with DDD if it's justifiable.

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

Anyway, at the risk of this answer sounding to 'academic' I'll now try to answer your question assuming you still want to model this as DDD:

对我来说，这都适合一个环境（称为安全性之类）

To me, this would all fit under one context (called 'Security' or something)

作为一般经验法则，将所有内容汇总为需要独立交易的总和，因此：

As a general rule of thumb, make everything an aggregate that requires an independent transaction, so:

1. 在系统允许的前提下对于要添加到 Authorization 对象的 Authorities ，请使 Authorization 为汇总。 （尽管可能存在放弃 Authorization 并仅使 User 成为具有 Authorities 列表的聚合根的论点）
$ b
2. 权威在 Authorization 聚合之外没有任何意义，并且仅在添加一个时创建，因此它们仍作为实体。


3. 假设系统允许将权限添加到角色，则角色成为汇总根。
b $ b
4. 假设无法创建/删除权限-即它们是由系统本身定义的，因此它们是简单的值对象。

1. On the assumption that the system allows for Authorities to be added to the Authorization object, make Authorization an aggregate. (Although there might be an argument for ditching Authorization and simply making User the aggregate root with a list of Authorities)
2. Authorities serve no meaning outside of the Authorization aggregate and are only created when adding one, so these remain as entities.
3. On the assumption that system allows for Permissions to be added to a Role, Role becomes an aggregate root.
4. On the assumption that Permissions cannot be created/delete - i.e. they are defined by the system itself, so these are simple value objects.

关于总体设计，我不能推荐这些文章足够。

Whilst on the subject of aggregate design, I cannot recommend these articles enough.

这篇关于有限的上下文和汇总根的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！