Specifications Pattern crossing bounded context - Domain Driven Design

Question

I'm trying to understand and implement with good practice the Specification Pattern within my domain driven design project.

I have few questions:

1. For example: verifying that a customer is subscribed before update a data on a aggregate is it part of business rule and should sit in the domain layer?

2. Can specifications cross bounded context? For exemple, i have a Subscription bounded context where we can find a specification called SubscriptionIsActive. In a second bounded context let's call it PropertyManagement. I would like to call SubscriptionIsActive specification as an User need to be a subscriber to create a Property aggregate. My specification here is crossing bounded context and i don't think it's right choice, any recommandation, tips?

3. Where should instanciate the specification when we want to use it, Application layer (that contains, commands and query, we use cqrs) or Domain Layer wihtin the aggregate root?

At the end, where should access control like (User has rights to edit some aggregate) sit in a domain driven design, Domain Layer or Application Layer in services before calling the aggregate?

Thanks

Answer 1

My recommendation is that a domain should not call out to obtain additional information/data. This means that everything a domain needs should be handed to it and the domain performs the transactional processing.

All authentication/authorization takes place outside the domain and access to the relevant domain operations is granted based on the identity/access outcome.

I have found specifications most useful on the data querying side of things. Usually there are multiple permutations w.r.t. how data is retrieved and a specification encapsulates the various possibilities quite nicely (GetByName,GetByNameAndType,etc.) This doesn't mean that you cannot use a specification in the domain. You may have some complex piece of functionality to determine qualification of a domain object and in that case a specification operating on the relevant domain object would be a good fit. To that end a specification doesn't cross a domain as it would be part of a particular domain. In much the same way as a specification is useful in a data querying scenario you may have a specification in the integration/application concern and have it determine qualification based on data from multiple domains such as in your second example. This may even be something that is applied in a process manager implementation (integration).

Not all business rules need to be specifications and if, as in your first case, a customer is not subscribed then your integration/application processing would stop any further transactional changes much as it would for an authorization failure.