I have a tree of Zone
objects:
class Zone {
protected $parent;
public function __construct(Zone $parent) {
$this->parent = $parent;
}
}
There are no children
nor descendants
property in the Zone, because I want to avoid the pain of managing these relationships in the domain model.
Instead, a domain service maintains a closure table in the database, to map a zone to all its descendants, at any level.
Now, I have a User
which can be assigned one or more Zones:
class User {
protected $zones;
public function assignZone(Zone $zone) {
$this->zones[] = $zone;
}
}
My problem is that, prior to assigning a new Zone to the User, I'd like to check that this Zone is not already assigned, either explicitly or implicitly via one of its descendants.
Therefore I'd like my controller to transiently inject the Service into this method, to perform the necessary checks:
class User {
protected $zones;
public function assignZone(Zone $newZone, ZoneService $zoneService) {
foreach ($this->zones as $zone) {
if ($service->zoneHasDescendant($zone, $newZone)) {
throw new Exception('The user is already assigned this zone');
}
}
$this->zones[] = $zone;
}
}
Is that a good practice, or if not, what's the correct alternative?
Dependency injection of a Repository or Domain Service into an Aggregate should generally be viewed as harmful. The motivation may be to look up a dependent object instance from inside the Aggregate.
A domain entity in DDD must implement the domain logic or behavior related to the entity data (the object accessed in memory). For example, as part of an order entity class you must have business logic and operations implemented as methods for tasks such as adding an order item, data validation, and total calculation.
Domain Services (or just Services in DDD) is used to perform domain operations and business rules. In his DDD book, Eric Evans describes a good Service in three characteristics: The operation relates to a domain concept that is not a natural part of an Entity or Value Object.
There are no children nor descendants property in the Zone, because I want to avoid the pain of managing these relationships in the domain model.
Instead, a domain service maintains a closure table in the database, to map a zone to all its descendants, at any level.
I added some emphasis because it seems a bit contradictory. You don't want the 'pain' in domain, yet you manage closure table in domain service. The fact that you need to inject service into entity sometimes indicates that design can be improved.
It looks like you have a hierarchy of Zones. This seem to be an important part of your domain. Zones have parent and descendants so maybe you should model it accordingly. Pain of managing the relationship is a 'justified' pain because you doing it for the sake of model expressiveness. The domain drives the design in this case. So zone itself will have something like:
zone->hasDescendant($newZone)
And you would not need to inject a service. In fact you would not need a service at all. Because the only reason for this service is maintaining closure table. Which is not a domain concern and is just a persistence issue.
If for some reasons you still need service it might be better to inject it into Zone class. This way the problem is solved closer to its source.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With