Relationship between objects in DDD

Question

I am starting to work with DDD, working on small, simple domains to get an idea of ​​all the design principles.

I have this simple domain: Institution and their available WiFi points ( Place ) are stored in a database. No place can exist without an institution. The institution has a manager-user-successor ( User ), which has the right to add new places, redistribute or delete existing ones.

The code can be found here . At the moment, validation of value objects is left.

This is affected by Mathias Verraes on child objects .

Is this the correct DDD design? or at least close to it?

As a data-oriented programmer, I am still wondering how I would list all the places for all Institutions if the rule of thumb has access to aggregates through an aggregate root?

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

Should there be an idea that only the User assignee can add / remove places that will be expressed in the domain itself or should it be responsible for the client? In this case, it would be reasonable if the assignee knew about his managed institution ( institutionId in User ?).

Isn't Institution::placeById violating any DDD principles? Perhaps this is the responsibility of the repository?

Answer 1

The cumulative root rule applies only to the write side. This problem will disappear if there is a special reading model. You can freely project on models that are suitable for your custom scenario.

In addition, you can add all places from institutions to the hash to set the return, which has flattened the list.

When compacting aggregate roots, consider an upgrade scenario. Can data be updated regardless of institution? If yes. Then it can be its own root.

Typically, the repository should specify the following identifier.

Express user rights through roles that contain a list of permissions. In each method, the sender is transmitted and access is checked inside the methods. It also makes it easy to check permissions.