Ok to have unbound roles in a DCI Context?

I'm working on a CreditCardPayment context, and found this possibility that not all roles are needed for some context methods. For example, the method CreateSecurityHash may require all roles, but VerifyHash only requires one. Is it ok not to bind all roles? If so, what about introducing multiple constructors and only bind what's needed, like this:

public CreditCardPayment(objectA, objectB, objectC)
{
  BindRoles(objectA, objectB, objectC)
}

public CreditCardPayment(objectA)
{
  BindRoles(objectA, null, null)
}

It feels difficult though to know what context methods are allowed to call when doing this. So I'd like to know:

• Is this still ok (if so, why?), or
• Is the whole scenario a sign that another context is needed, or
• Should I keep the context and supply all objects needed for the roles, always?

If you feel like not binding all roles there's a few questions you should go and ask your self. You've already asked one of them "Should I create two contexts?" to answer that question I'd look at the context as a hole. If it does indeed model one process then don't divide that into several. We wish to model the end users mental model. If that model is complex there's nothing we can do to change that but we can help by reflecting it.

In your particular case it would seem that you are indeed modelling one process in which case you should keep the context as one. Boind the roles once and know that from that point on you are safe to call use the interactions.

Not binding roles will lead to code that is unnessecarily hard to reason about. "Will it be safe to call this method?" you will only be able to answer that at runtime when you can see which roles have been bound. All roles are always bound at the same time at this happens prior to the interaction or is the first part of the interaction