设计模式 – 在DDD中实现聚合级别权限的位置？

假设我有一个聚合类型的Order,它包含OrderItems.根据订单的状态以及在其上运行的用户角色,可以允许或不允许操作.

例如,如果用户角色是Customer且订单的状态为“打开”,则允许添加和删除项目.相反,如果订单的状态为“处理”,则不允许添加和删除项目.但是,如果用户角色是Manager并且订单的状态为Processing,则允许添加和删除项目.

我的问题是：

>订单类型应该处理这些类型的权限吗？也就是说,它封装了关于哪些角色可以做什么的所有逻辑,因此依赖于用户角色.
>或者是否应在可接受角色,操作和操作主题(订单实例)的权限服务中的Order类型之外处理,并确定是否允许该操作？即,逻辑被外化并假定在对Order执行操作之前进行验证,Order不知道用户角色的概念.

(注：实际使用情况是大量的角色,状态和行为显著更复杂的授权发生在外层和已经被应用 – 这个问题是关于例如特定权限换句话说,一个客户是.授权访问“AddItemToOrder”API端点,但根据订单的具体状态,可能允许或不允许实际操作.)

我更喜欢将访问控制视为应用逻辑而不是域逻辑,因为并非所有域操作调用都来自人类用户并且需要访问控制.将权限放在单独的交叉层或不同的有界上下文中也有助于分离关注点.

在您的示例中,我将尝试为客户和经理采取的操作提出不同的域方法名称.当你在与类似但略有不同的概念斗争时,丰富无所不在的语言可能是一个很好的仲裁者.