Years ago, I published a design pattern (a solution that could be applied to a common, recurring problem. Hence, the name 'pattern'). I named it 'Multi Key Lock'. Here's a brief...

The multiple key locks are unlocked only when all the keys are used. Similarly, there are situations where multiple conditions needs to be satisfied for an event to come to pass -- possibly (and, most likely), across different components / modules. In such cases, this pattern comes in handy.

This pattern propounds a lock object that represents a specific condition or state that comes to pass when a chain of events or conditions occurs. The 'clients' of this lock object are the players (i.e., modules or components) that affect the condition in some way.

The lock object exposes an API for the clients to try unlock. Whenever a particular client's state requires to unlock this, it invokes the unlock API. This triggers an evaluation process, which is invoking a callback function in every client. The callback functions are supposed to return a boolean value -- as to whether, that particular client 'thinks' it is in a state suitable to unlock. In case, all the parties return true, the lock object gets unlocked, and it notifies all the parties of its state.

The parties or clients of this lock object does not have to know the other parties involved -- thereby, averting the need for any dependencies amongst one another.

Note the striking similarity with a AND gate, which evaluates to true, only when all its inputs are true. Hence, an alias name 'AND' condition).

Find the link to the actual write-up published here.

Cheers!