Command Handling Policy / Strategy Pattern in Application Services

AssignEmployeeHandler.php

<?php

namespace Rewotec\TimeTracking\Application\Employee;

use Rewotec\TimeTracking\Domain\Model\Employee\AssignableJobFunctionPolicy;
use Rewotec\TimeTracking\Domain\Model\Employee\Employee;
use Rewotec\TimeTracking\Domain\Model\Employee\EmployeeRepository;

/**
 * Class AssignEmployeeHandler
 * @package Rewotec\TimeTracking\Application\Employee
 * @author Michael Borchers <m.borchers@rewotec.com>
 */
final class AssignEmployeeHandler
{
    /** @var AssignableJobFunctionPolicy $jobFunctionPolicy */
    private $jobFunctionPolicy;

    /** @var EmployeeRepository $employees */
    private $employees;

    /**
     * AssignEmployeeHandler constructor.
     * @param AssignableJobFunctionPolicy $jobFunctionPolicy
     * @param EmployeeRepository $employees
     */
    public function __construct(AssignableJobFunctionPolicy $jobFunctionPolicy, EmployeeRepository $employees)
    {
        $this->jobFunctionPolicy = $jobFunctionPolicy;
        $this->employees = $employees;
    }

    /**
     * @param AssignEmployee $command
     */
    public function __invoke(AssignEmployee $command)
    {
        if (!$this->jobFunctionPolicy->isSatisfiedBy($command->jobFunctionId())) {
            // Employees whose job function is not linked to an activity are not assigned.
            return;
        }

        $employee = Employee::assign(
            $command->employeeId(), $command->personnelNumber(), $command->firstName(), $command->lastName(),
            $command->companyId(), $command->startDate(), $command->leavingDate(),
            $command->workerCategory(), $command->jobFunctionId()
        );
        $this->employees->add($employee);
    }
}

After receiving data from a producer my application has to check a policy that decides if the data should be transformed and persisted inside microservice at all. Where would you put that "validation"?

Vote here:

• https://twitter.com/webdevilopers/status/951788151529463808

I would pass the jobFunctionPolicy as a dependency of the assign constructor. This way, you are always sure that no matter where you want to create a new Employee, the policy is checked. It's part of your business requirements.

About my current solution:

I find the Process Manager for validation the wrong place. Maybe there will be multiple entry points soon that will then use the command bus to dispatch the "assignEmployee" command. Some would then be able to pass the validation.

Normally I inject a policy into the Aggregate Root. Problem is that it's not necessary to throw Exception, just skip creating / adding the AR / publishing events at all. A named constructor would return null. A command handler should not have to deal with something like that.

A domain service or factory may put the policy into the domain layer but feels like an extra added layer / complexity.

What is wrong with:

• Throwing an exception & catching it in the Handler?
• Returning null and checking for it in the Handler?

Throwing an exception feels like something went "wrong". But actually it's not the case. The data per se was valid. The application is just not interested in storing the data at all.

I like my handlers to simply store of fail. But not to check something in between. That is "superficial" validation and feels better before the attempt to create and store.

Where does the AssignEmployee command come from? And who is interested in the result?

A Process Manager / Consumer receives all employees. It then creates the AssignEmployee command.
Currently then the Command Handler gets injected a Policy that decides if the command holds the correct JobFunctionId.
If not, the Command can be ignored. Otherwise the Aggregate Employee can be created and stored inside the Repository.