webdevilopers
commented
7 years ago I took another look into "Practices of Domain-Driven Design" (@PPDDD) by @elbandit and @NTCoding. In chapter 19 p. 433 there is a concrete example showing how to work with IDs only and still have the other AR check the invariants.
The solution for my example should look like this:
use Acme\Contract\Application\Service;
class WriteTimeSheetHandler
{
public function handle($command)
{
$contract = $this->contractRepository->find($command->contractId());
$timesheet = $contract->writeTimesheet($command->start(), $command->end()); // Check invariant
$this->timesheetRepository->save($timesheet);
}
}The only thing I wonder is how to enforce the invariants checked? Since a developer could still use the constructor of the Timesheet AR by simply passing the required contractId.
Or is it enough to make the constructor private and use a static factory method on the Timesheet AR? Still a developer could create the aggregate without going through the invariant of Contract.
As far as I understand the invariants have to be enforced for the "outside world" - the User and its Interface - "orchestrated" by the Application layer.
I wonder how to adapt these rules if a new AR is added e.g. an Employee who can only work for a certain time range and is - of course - not allowed to work twice a the same time.
Now we have two AR having to check invariants. I guess this is the right place for an Domain Service, right?
use Acme\Contract\Application\Service;
class WriteTimeSheetHandler
{
public function handle($command)
{
$timesheet = $this->timesheetService->write(
$command->contractId(),
$command->employeeId(),
$command->start(),
$command->end()
);
$this->timesheetRepository->save($timesheet);
}
}use Acme\Contract\Domain\Model;
class TimesheetService
{
public function write($contractId, $employeeId, $start, $end)
{
// Get aggregate roots from injected repositories.
// Check invariants with simple methods like `isClosed` etc.
$timesheet = new Timesheet(...);
return $timesheet;
}
}
NTCoding
yvoyer
prolic
msphn
We have a
ContractDomain Model holding a huge collection ofTimesheets. I just added some simple Symfony code snippets using Doctrine Entities and Annotations. All Entities are later moved to Acme\Contract\Domain\Model namespace and XML Mapping inside Acme\Contract\Infrastructure\Persistence\Doctrine etc..Currently we are using CQRS and a single Symfony app. Using Contract as the only AR forces our policy on the invariant:
There can be many related timesheet aggregates. This gives us the hint that Timesheet itself should be handled as an Aggregate Root (AR):
Another solution we thought about is creating a new Contract Domain Model inside a different Bounded Context where the Timesheet will be living in. This would lead us to Eventual Consistency but it would be possible with our current infrastructure where bounded contexts are shared across the app.
As suggested by @mgonzalezbaile:
But this way the Contract still has the relations to existing timesheets and all of them would be loaded.
Other thought on large aggregates by @voroninp:
Instead of loading all the timesheets we thought about removing them completely from the Contract. The only connection would be on the Timesheet aggregate via reference (ContractId):
Still we would load the Contract Aggregate and pass it to the Timesheet aggregate in order to check the invariant. But passing the Contract AR to the Timesheet constructor doesn't feel good.
Another variation is moving the policy out of the Timesheet into a Domain Service. This Domain Service CanOnlyAddTimesheetToPendingContract could receive the contract repository. I think this is absolutely legal in DDD. We would only have to pass the ContractId to the constructor instead of the full domain model.
Though I like this approach @VoiceOfUnreason states here for a similar example:
Which is to say, if the rules for modifying a Timesheet depend on the current state of the Employee entity, then Employee and Timesheet definitely need to be part of the same aggregate, and the aggregate as a whole is responsible for ensuring that the rules are followed.
An aggregate has one root entity; identifying it is part of the puzzle. If an Employee has more than one Timesheet, and they are both part of the same aggregate, then Timesheet is definitely not the root. Which means that the application cannot directly modify or dispatch commands to the timesheet - they need to be dispatched to the root object (presumably the Employee), which can delegate some of the responsibility.
Related: