Relation between entities in DDD

Question

I am a beginner on DDD, working around small, simple domains in order to get my head on all the principles of design.

I have this simple domain: institutions (Institution) and their available WiFi spots (Place) are kept in the database. No place can exist without an institution. Institution has manager user - assignee (User), which has the right to add new places, reallocate or delete existing ones.

Code can be found here. The validation on value objects is left behind for now.

This is influenced by Mathias Verraes on child entities.

Is it a correct DDD design? or at least close to it?

While being a data-centric programmer, I still wonder how would I list all the places for all the Institutions, if the rule of thumb is accessing aggregates through the aggregate root?

Is the idea of generating Uuid inside of the entity itself (Place::create) good?

Should an idea, that only assignee (User) can add/remove places be expressed on the domain itself or should it be the responsibility of client? In this case it would be wise if the assignee would know about his managed institution (institutionId in User?).

Isn't the Institution::placeById breaking any principles of DDD? Maybe it is the responsibility of the repository?

Answer 1

The aggregate root rule only applies on the write side. This problem will go away if have a dedicated read model. You should be free to project to read models that are suited to your user scenario.

Else you can add all places from institutions to a hash set an return that flattened list.

When designing aggregate roots think about the update scenario. Can place be updated independently of institution? If yes. Then it might be an aggregate root of its own.

Normally repository should determine next ID.

Express user rights via roles containing a list of permissions.in every method pass the sender and check for access inside methods. This also allow easy testing of access rights.