Reputation: 23
A user has a user type and these user types are stored in a database with their own attributes and some id to reference it into the user table.
case class User(id: Int, userType: Int, firstName: String, lastName: String)
case class UserType(id: Int, name: String)
Also I have an aggregation object.
case class User(userData: User, userType: UserType)
Application managers can create their own user types and assign them to the different application users.
Additional information: These user types cannot be modified once created, but could be deleted after passing some validations.
Should the user type be an entity (because it needs to be stored with some id) or be a value object (because two user types with the same values, except the id, are in fact the same object)?
EDIT
Application managers can create their own user types so UserType needs to have its own repository, that's clear. User repository can have just the reference of user type instead of having the user type itself, but the question is if the user type can be treated as an entity or a value object.
Upvotes: 0
Views: 1549
Reputation: 176
I think your question comes from persistence concerns rather than from the business domain. Is there any sense in having two user types with the same name, but different ids? If the answer is "no" then this is definitely a Value Object.
Upvotes: 1
Reputation: 8785
I think that both.
In the context of "User Management" you create or modify a User using a userType VO that can not be chaged. Create a User and ask for a userType (VO) in cosntructor or use aggregate/entity function to modify user type. i.e.: User.ChangeType(userTypeVO).
When you are in i.e.: "YourSystem Configuration Context" you should treat UserType as entity becasue you have to reference it to delete, modify (fix a spelling error maybe?) or create new userTypes.
Upvotes: 1