DDD: is it ok to inject a Service into an Entity
Asked Answered
G

1

8

I have a tree of Zone objects:

class Zone {
    protected Zone $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 array $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 array $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?

Guacharo answered 19/9, 2011 at 17:50 Comment(1)
related: #4835546Ausgleich
Q
5

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.

Quaint answered 19/9, 2011 at 19:47 Comment(2)
Exactly, first term of the question title is : DDD. The design should be driven by the domain, not your laziness :)Wilbertwilborn
I followed your advice, and that indeed makes more sense now. I added a $descendants property, mapped it to the closure table, and removed the service dependency. For now I'm never "moving" my Zone to another parent, just adding/removing zones, so that makes the design simple enough! I still have an external service to rebuild the closure table, just in case a design bug would corrupt it, though.Guacharo

© 2022 - 2024 — McMap. All rights reserved.