Specialization hierarchy in a domain-model

I'm trying to make the domain model of a management system. I have the following kind of people in this system:

employee
manager
top mananger

I decided to define an User, from where Employee, Manager and Top Manager will specialize from. Now, I don't know what kind of specialization hierarchy I should choose from. I can't decide between the following ways:

or

Which might be preferable and why?

As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.

Thanks

EDIT:

I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might appro开发者_StackOverflowve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.

This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.

One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).

On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).

In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:

User -> Employee -> Manager -> Top Manager 

edit

"This is a program to manage the vacations plans of workers."

In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:

User -> Requester
     -> Approver

Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.

You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.

Edit 2

Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.

Let's see. Each User fits into a single category, defined by these tasks:

• an Employee can Request leave
• a Manager can Approval or Reject a Leave Request
• a Top Manager can Accept or Overturn an Approval or Rejection

Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.

I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.

The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.

The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.