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?

  • When the company owner acts as a customer, does he/she really use the user account of the owner or rather just another regular customer account?
    Oct 14, 2016 at 5:52

1 Answer 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.