1

I have a AR called User, which has among other entities one called City.

The way I assign a City to a User is: $user->addCity($city);

The problem comes when a id is given at some Controller endpoint instead of a City entity, I can't relate them if it's not through an instance and I can't retrieve the entity intance without a repository.

I could retrieve the entity with a CityRepository and then add it to the User but I though I should only use a repository for ARs.

For the moment, I'm getting the reference through Symfony's EntityManager:

    public function __construct(UserRepository $users)
    {
        $this->users = $users;
    }


    public function execute(Passenger $user, int $cityId, string $companyName = '')
    {
        $city = $this->users->getCityReferenceById($cityId);
        $user->addCity($city);
        ....
    }

while on UserRepository:

public function getCityReferenceById(int $cityId): City
{
    return $this->em->getReference(City::class, $cityId);
}

2 Answers 2

1

I think the question here is; do you need a whole city object for the User?

Fair a user is a resident in a city, but in this particular domain, are you concerned with the city details (name, country, etc) from the perspective of the user? or will just having the cityId suffice? - that is to say, would your require functionality to change the name, country, etc. of a city through a User?

If the Answer to the former is yes, then I suggest revisiting your Aggregate, perhaps User is not the AR here. If no, and you just want to have the full city details for the purpose of populating a view, then perhaps look into CQRS, which aims to separate concerns of query/read/display side by introducing a separate read model.

1
  • Thanks, answer is clearly No. I'll take a deeper look into CQRS. So many thinks to learn omg Nov 23, 2018 at 16:29
1

I think the issue you are describing (and therefore the use-case you necessitate) is being caused by boundaries being drawn in the wrong places. A City is clearly an Entity in it's own right subject to it's own vectors of change. For example, clearly you wouldn't change the name, population, etc. of a City through a User.

The relationship between a City and a User seems to be the more interesting idea in your domain, and one that you have not yet made explicit. One can imagine a Residence (or maybe a better word) as representing the join between a User and a City that contains additional information about a given User's relationship with a City.

These attributes could be placed on your [User] table along with the [CityId] or separated into a join table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.