Four eyes principle applied with commands

gistfile1.txt

1. When the user adds an accountnumber, a command gets sent which isn't handled yet.
2. When a supervisor logs on, he gets a list of commands to approve or decline, including the AddAccountNumber.
3. When the supervisor approves the AddAccountNumber command, it will be handled.

You're doing it wrong: Picture > 1000 words
You need to make workflow explicit instead of wiping it under the carpet that says "Technical Shit Here".

This will work fine, but it feels a bit wrong. The problem is here: "a command gets sent which isn't handled yet.". You are adding a step in between the sending and the handling of the command. In other words, you are exposing the knowledge about this extra step to whoever sends commands.

I feel that the api shouldn't change: when you have a command, you give it to a command handler, period. Normally, command handler handle the command immediately. In this case, some command handlers (SupervisedCommandHandler) hand over the command to SupervisorApprovalWorkflow. This class will tell the command handler whether the command was approved, or is pending approval.

SupervisorApprovalWorkflow will store the command somewhere, so a supervisor can approve it. This is in turn a new command, that wraps the old one: new ApproveCommand(AddAccountNumberCommand).

The ApproveCommandHandler delegates the original command back to the AddAccountCommandHandler. Again, that handler asks the SupervisorApprovalWorkflow whether the command is approved. This time, it will say yes, and the command gets handled for real.

Just some brainstorming, YMMV. This is perhaps to much extra work for a basic use case. But it would allow for more flexibility if you later discover you need more steps in the process, different people with approval/proofread/publish/... permissions.

In any case an interesting modelling problem :-)

I agree with both replies; I hadn't fleshed out the details yet. But I do know this doesn't belong on the entities themselves ;)

The problem IMO is that the modeled commands don't capture the language. There are two commands here: one is a request for approval, the other is the actual work to be done once it is approved. Digg deeper into what the supervisor and end user want. What's the message flow upon decline? Chances are you'll need to notify that end user (indirectly using a list or a status on his original request). Maybe you'll uncover that a request is a separate thing in your model the end user wants to interact with (i.e. the request he wants to follow up on). The hardest part is giving these things a name.