Hello stackoverflow members,

I'm using pure PHP to implement a Domain Model. I have two entities, entity dog and entity human which acts as the owner of the dog.

This is a many-to-many relationship. A owner can have more than one dog and a dog is owned by many humans (let's say the dog belongs to a family or a couple).

I have a database table for dog and human and also the n:n connection table. I have the two entities which are POPOs. And I also have two repositories, one for dog and one for human. These repositories have the crud operations and are responible for the database queries.

Which repository is responsible for managing the n:n table?

Example:

entity dog has a property array with all connected human's and vice versa. If i create a new human like: $human = new Human('name'); and let him own an already existing dog like: $human->addDog($dog); Who is responsible for the n:n connection?
I can do $dogRepo->Update($human->getDogs()[0]); to update the dog in DB or I can do $humanRepo->Insert($human). Should the DogRepo also insert the new human (utilizing the HumanRepo)? Should the HumanRepo also update the dog (utilizing the DogRepo). Or is the business logic responsible for this? (call insertHuman() and updateDog() seperately from the business logic).
On all of this approaches I don't know which repository is responible for the n:n table?

Sound like a common question but i couldn't find a suitable solution on the web.

Thanks in advance!

In DDD we design our Aggregates based on the business rules. Each Aggregate protects its own invariants. There are no tables or relation tables in our head when we design them, just invariants and consistency requirements.

That being said, you are having difficulties because you haven't identified the invariants or there are none.

Does the human that own a dog behave in some particular way? Are some human commands rejected if the Human doesn't/does own a Dog ? Then you add to the Human Aggregate a list of owned dog ID's (and not dog instances!).

Does the dog that is owned by a human behave differently from a dog that has no master? Then add to the Dog Aggregate a list of owner IDs.

Or is this relation between them shown only in the UI? Then add it as a separate Aggregate, i.e. DogOwnershipByAHuman(id, dogId, humanId) to not pollute the Dog or Human Aggregates with data that they don't need.

Both repositories should only change their corresponding tables, since this is their main functionality (following the Single responsibility principle). These repositories would be wrapped by a Service (a wrapper class which has utility functions for managing relations), where the service would be responsible for altering both databases correctly. So this service could have a function like assignDogToHuman($humanId, $dogId), where this function would call both repositories and change their data accordingly.

By doing this you make sure that the repositories have one responsibility (updating their own table) and the service has the responsibility of managing the relations between dogs and humans.

This also provides you with the added benefit that the repository layer is now replaceable. I.e. if you ever decide to change the database (for example from Mysql to MongoDB), only the repositories have to be swapped/updated since the implementation of the functions called by assignDogToHuman should stay the same and for this service it does not matter what the underlying database is.

I hope this helps you, if you have any questions feel free to ask