design-patterns - 在 DDD 中在哪里实现聚合级别的权限？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




假设我有一个 Order 的聚合类型，其中包含 OrderItems .根据订单的状态和对其进行操作的用户角色，可能允许或不允许操作。

例如，如果用户角色是 Customer并且订单状态为 Open ，则允许添加和删除项目。相反，如果订单的状态是 Processing那么不允许添加和删除项目。但是，如果用户角色是 Manager并且订单状态为 Processing然后允许添加和删除项目。

我的问题是:

应Order类型处理这些类型的权限？即，它封装了关于哪些角色可以做什么的所有逻辑，因此依赖于用户角色。

或者这应该在 Order 之外处理输入将接受角色、操作和操作主题(订单实例)并确定是否允许操作的权限服务？即，在 Order 上执行操作之前，逻辑被外部化并假定已验证。 ，它不了解用户角色的概念。

(注意:真实世界的用例要复杂得多，有大量的角色、状态和操作。授权发生在外层并且已经应用​​——这个问题是关于实例特定的权限。换句话说，客户是授权访问“AddItemToOrder”API 端点，但根据订单的具体状态，实际操作可能允许也可能不允许。)

Answer 1

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

在您的示例中，我会尝试为客户和经理采取的操作提出不同的域方法名称。当您在处理相似但略有不同的概念时，丰富无处不在的语言可能是一个很好的仲裁者。