I have a question about modeling.
Quick introduce: I develop application to sales purposes. Application have users. Every user could be customer, employee or companyOwner.
It depends on:
Customer – just registered account, and buy product form any registered company
Employee – registered account, and company owner assign employee role to him.
Company owner – registered account, and created store.
but company owner could be also a customer, just like employee.
i came with simple relationship
class user
class customer : user
class employee : user
class companyowner : user
In that way i can easy encapsulate logic for each ROLE? (the role is keyword) In worst scenario i could map everything in BD to table per subclass scenario.
Or i should leave user simple, and create role hierarchy, that encapsulate logic?
class user class role class customer : role class employee : role class companyOwner : role
and with simple associations i could
user.AssignRole(new Employee(company));
user.Roles.where(x => x is Employee).DoSth()?
BTW: I could rename “role” to “actor”
What about aggregate root in both cases? If i use same entity(user) as customer and same entity(user) as employee.
What about when 2 or more peoples use the same entity in the same time with different boundingContext (customer, employee)?
The main question is: It is good design if one database entity could be shown in many types?
1
I think I’d prefer composition over inheritance here. The complexity of subclassing doesn’t seem warranted. I’d separate people (users) from their roles; to say it another way, I don’t think an is-a relationship is merited between people and their roles.
For example, roles change. And for another, one person can fill multiple roles (and that’s hard to model with subclassing).
Let the people structure be about the people and role structure about roles, and associate/link them as needed.