领域驱动设计 – 有界上下文和聚合根
|
我们正在尝试使用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
在典型的场景中,授权绝对是聚合根,因为用户维护中的所有内容都围绕着这一点(例如,我可以授予用户一个或多个权限,即角色或权限) 我的问题是：角色和权限怎么样？它们也是各自背景下的聚合根吗？ (即我有三种情况,授权,角色,许可).虽然可以在一个上下文中组合所有,但是角色不会太重,因为它将作为授权“对象图”的一部分加载吗？ 解决方法
首先,我不禁感到你误解了有界背景的概念.你所描述的BC是我所描述的实体.在我看来,有限的上下文有助于使普遍存在的语言中定义的实体对于给定的上下文具有不同的目的.
例如,在医院领域,在门诊部门接受治疗的患者可能有一个推荐列表,以及诸如BookAppointment()之类的方法.然而,被视为住院患者的患者将具有Ward属性和方法,例如TransferToTheatre().鉴于此,患者存在两种有限的背景：门诊患者和患者.住院病人.在保险领域,销售团队制定了一项政策,该政策具有与之相关的风险程度,因此也就是成本.但如果它到达索赔部门,那么这些信息对他们来说毫无意义.他们只需要验证该政策是否对索赔有效.所以这里有两种情况：Sales&声明 其次,您是否只是在尝试实施DDD时使用RBAC作为示例？我问的原因是因为DDD旨在帮助解决复杂的业务问题 – 即需要计算的地方(例如政策的风险).在我看来,RBAC是一个相当简单的基础结构服务,它不涉及实际的域逻辑,因此不保证严格的DDD实现. DDD的投资成本很高,你不应该只是为了它而采用它;这就是为什么有界上下文很重要的原因 – 如果它是合理的,只能使用DDD对上下文进行建模. 无论如何,冒着这个答案听起来’学术’的风险,我现在会尝试回答你的问题,假设你仍然想把它建模为DDD： 对我来说,这一切都适合一个环境(称为“安全”或其他) 作为一般经验法则,将所有内容都设置为需要独立事务的聚合,因此： >假设系统允许将Authorities添加到Authorization对象,请将Authorization作为聚合. (尽管可能存在放弃授权并简单地将User作为权限列表的聚合根的论据) 虽然在总体设计方面,我不能推荐这些articles. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |