53 backend core core model group entity implementation 2

[rvdkeere]

Implementation of the Group entity with a list of members (Student objects) and an add & remove member method instead of a setter to better conform to domain rules of clean architecture

[lennertdr]

Thoughts:

1. Why keep full Student objects in a group? Thought we would minimize info by only using id's or fetching the data we need.

2. Here the group-id is readonly and could be null, so when a group object is made without id (before creating it in the database), it can't be changed later. Can't this be a problem?

[rvdkeere]

@lennertdr

1. I based this approach on the idea that a group and its members are more closely tied together than, say, a student and their classes. It also more closely follows the principles of clean architecture by keeping the domain more object oriented. However if there are common use cases where only the group is needed, without accessing its members, then minimizing info could indeed be the better choice here.

2. I don't see when this would be a problem. The moment you store the object for the first time it gets assigned an id, and any subsequent use case fetching the object will get that id with it. Are there any cases where an entity's id should be changed after creation? If not, it seems safer to keep it readonly.

[brentjan]

I thought we agreed that an entity should not have a direct list of other entities it has a relation with? But that an entity should have a list of id's?

[rvdkeere]

Due to popular demand and to remain consistent with other entities, I replaced the list of student objects with a list of ids with a basic setter.

Changed