Domain driven design 规范模式跨越有界上下文-领域驱动设计

我正试图在我的领域驱动设计项目中理解并以良好的实践实施规范模式

我有几个问题：

例如：在更新聚合上的数据之前验证客户是否已订阅，这是否属于业务规则的一部分，是否应位于域层

规范可以跨边界上下文吗？例如，我有一个订阅限制的上下文，在这里我们可以找到一个名为SubscriptionIsActive的规范。在第二个有界上下文中，我们称之为PropertyManagement。我想调用SubscriptionsActive specification，因为用户需要成为订阅者才能创建属性聚合。我在这里的规范是跨边界的，我认为这不是正确的选择，有什么建议吗，提示

当我们想要使用规范时，应该在哪里实例化规范，应用层（包含命令和查询，我们使用CQR）或聚合根中的域层

最后，在调用聚合之前，访问控制（如用户有权编辑某些聚合）应该位于服务中的域驱动设计、域层或应用程序层的何处

---

谢谢

我的建议是，域不应呼叫以获取更多信息/数据。这意味着域需要的一切都应该交给它，并且域执行事务处理

所有身份验证/授权均在域外进行，并根据身份/访问结果授予对相关域操作的访问权限

我发现规范在数据查询方面最有用。通常有多个排列w.r.t.如何检索数据以及规范如何很好地封装各种可能性（

GetByName

，

GetByNameAndType

，等等）。这并不意味着您不能在域中使用规范。您可能有一些复杂的功能来确定域对象的资格，在这种情况下，在相关域对象上操作的规范将非常适合。为此，规范不会跨域，因为它是特定域的一部分。与规范在数据查询场景中有用的方式大致相同，您可能在集成/应用程序关注点中有一个规范，并让它基于多个域（如第二个示例中）的数据确定资格。这甚至可以应用于process manager实现（集成）

并非所有的业务规则都需要是规范，如果像第一种情况一样，客户没有订阅，那么您的集成/应用程序处理将停止任何进一步的事务更改，就像授权失败一样