print-Eruki
commented
4 days ago Ready for review, made changes to the sections 2.1.2 terminology and to section 2.3.2 repository Pattern and Aggregates
Address comments on terminology and how the project implements repository pattern and aggregates. Change it to have can we create the aggregates based on the domain instead of what is implemented
@Keiven-Soto @ebrain-mendoza121
Please fix the section according to the following critique from the professor:
Whether or not the user should be the root of an aggregate that includes the room is doubtful: should rooms not have global identity? Should they not be found without having to go through the owner of the room? Is there the possibility that a room gets transferred from one user to another (even if that's currently not implemented)? How about recording which rooms a user is participating in (just as a player, not as owner)? Don't we want to be able to say "player A plays in rooms X and Y" as opposed to "player A plays in player B's third and fourth rooms". Remember, if the rooms are within the aggregate boundary then there cannot be any reference to them from outside the aggregate.
From what you write about the way you came up with the aggregates it sounds like you went about it backwards. We want to look at the domain and decide what the aggregates should be and then implement them. You seem you have taken the implementation and then created the aggregates to reflect what's already in your implementation.
From the domain perspective, you don't really want to talk about "user", it makes more sense to talk about "player". Also, in real life, does it make a difference so the play or the rules whose table it is that's being played on? If not, then "owner" might not be a domain concept, but instead just something that you came up with to ease the implementation. Maybe that concept should therefore be abandoned. On the other hand, if you do have good reason to distinguish the player who is the owner of a table from all the other players playing on the same table and that reason comes from the domain, then it actually is a domain concept. But I know too little about dominoes to know which way it is. I'd suspect that it does not make a difference... Even if it is not a domain concept you might still have other reasons to distinguish the owner of a room from the other players, but the need to do so would then be an application concern, not a domain concern. Therefore, keeping track of who the owner is and all other functions related to the ownership would have to live in the application layer.
You might end up having separate classes, one representing "user", one representing "player", one representing "table owner". Player is definitely from the domain. User is definitely from the application.