0

Suppose I have an application where I can manage clients (just companies I offer my services to) and what services I offer for them. I also have the functionality to create timebookings, which means I can say "I did 3h of Service X for Client Y". The timebooking needs to know which employee did this. Now in the ubiquitous language the person who did the service is an employee. But this employee has to be registered first into the system and get username and password, which creates a user object. Also I will have an additional concept of Supervisor which can see all the time bookings of his employees. The supervisor also is just an account with a login.

How would I connect the employee to the user object? Lets say the employee login to the system and creates timebooking. How would I know which employee Entity to load? Do I store the userId in the employee entity or is the employees ID just the same as the userId of the user entity (which is in another context). What if I don't implement my own identity solution but use a third party service like auth0?

Improve this question

6 Answers 6

Reset to default
3

This requires much more analysis and investigation. This can't be answered by a stranger on the internet, it requires you to refine your actual business requirements.

Consider cases like these:

  • Andy works part-time for company A and part-time for company B. In both companies, he manages the time bookings, both companies use your tool. Does Andy need separate logins for these roles?
  • Bernard is an externally hired person. He is not expected to do the company's admin; this is done for him. Cindy the manager will input Bernard's entries. Does Bernard need a login?
  • Danny got into a serious accident before he could log this month's entries. He's unavailable for the next few months. How is someone going to enter his data (let's assume that such a person knows what to fill in)?
  • Eddie used to work for the reticulation department, he was able to claim for jobs X and Y. However, Eddie got transferred to the encabulation unit where he is now able to claim for job Z (but not X and Y anymore).
    • Eddie forgot to add an entry from before he was transferred, how can he fix this after the fact?
  • Frank keeps logging hours that are not correct. This is not malice, Frank just doesn't understand and seems unable to learn. How can Gale, Frank's manager, ensure that Frank's wrong entries are not added into the system?
  • Henry is at the same time Iain's supervisor and he submits entries for work he performs under Johnny's supervision. How will you represent/model Henry's account?
  • Kendra, a recently fired ex-employee has filed a request to delete all their PII (personally identifiable information) from your systems. However, the fiscal year is still months from closing and you need to retain their entries (without any PII). How do you intend to achieve this?
  • There is an ongoing role that is filled with casual employees who might do a job for you once and then never return. You don't really know about these people in advance, and the people who manage them cannot be bothered sending through requests for individual accounts multiple times a day, every day. They ask you to just create a "Job X worker" account that can be used by all these casual workers. How will you model this?

I'm just spitballing edge cases here that your question simply hasn't factored in yet. I'm not saying every case is useful for your specific scenario. However, I think your current approach is likely oversimplified to the point where if you build it the way you're thinking of right now, you're likely going to end up needing to fix/change the codebase as you later realize which edge cases you forgot to think about.

The key takeaway here is that you need to identify exactly how these concepts should operate under these circumstances, because that kind of refinement is what's going to drive your understanding of which design best fits your specific requirements.

Improve this answer
1
  • ok this helped a lot! I really need to do more digging into the domain and answer some of these questions which have to be considered in my case. Thank you very much for you help Commented Jan 31, 2024 at 16:10
2

What if I don't implement my own identity solution but use a third party service like auth0?

This is the dilemma that we all must face when designing a new system. It doesn't really matter if you are using DDD or other modelling patterns, if this is a real system that you want to integrate with the evolving industry then you will find that the most flexible model will abstract the concepts of Identity, Authentication and Authorization separately.

While and Employee can log in, should all things that login be Employees? For that matter are all things that login even Users?

Conceptually, Employee is a time constrained Role. You as a person will assume the role of Employee for many different Employers over your journey, you will also be a user of many systems without actually being an employee. Some of the time frames may overlap, each of those roles will have specific security roles that will govern the Authorization or Access that you have to the system. You might use a number of different trusted credentials linked to your Identity that can be used to Authenticate.

In the case of a Supervisor, this could simply be a security role assigned to a specific Employee, unless you have additional metadata that you intend for this entity to track that does not apply to an Employee.

Do I store the userId in the employee entity

I would model Employee and User separately. An Employee can be 1:0-1 linked to a User, ideally with a UserId assigned to an Employee (Employee has a UserId). If you did this the other way around then you would end up with many fields in your User entity such as SupervisorId and potentially ClientId. You can make it work, but it is not scalable to keep adding fields to the User entity as you evolve your solution.

This will also allow you to model the data for a past or future employee without having to grant them access to the system, it will also allow you to evolve the User requirements without affecting your business logic that is centred around your Employee implementation.

  • You should also consider the future growth opportunity of a client being able to login as their own User to view reports or otherwise access or provide information.

is the employees ID just the same as the userId

If Employee inherits from User (1:1) then you cannot have an Employee that is not also a User it will also become hard to associate multiple identities to your employee when that becomes important, or if you do then you will end up adding another entity to model Identity instead of your User entity.

It is up to you to decide which of these trade-offs you want for your model. 1:1 between User and Employee can certainly be made to work, there are many ways to do this, DDD does not specifically constrain us in either way. Take the time to understand the implications of your design decisions and evaluate them against the alternatives.

Improve this answer
0

It sounds like User models a human being, and Employee models a limited time employment contract with FK relationship to User. And the timestamp of logged hours should fall between hired and separated dates.

Improve this answer
0

As @J_H notes, User has a different purpose in the model than Employee.

Very often, questions about how to model users show that there isn't a clear understanding of the difference between persons and their roles within an application.

I would most likely start by differentiating between

  • Person - the data describing and identifying a person who interacts with or is known to the system.
  • Role - a role that a person assumes within the application. In an object oriented model, this might be an abstract class with a number of subclasses for specific roles, for example:
    • Employee - someone employed by a company who gets a salary and for whom timesheets are kept.
    • ExternalConsultant - someone employed by another company but who performs work for this company.
    • LoginUser - someone who can log in to the system who has certain access rights within the application.
    • ...

The roles depend very much on the actual needs of your application, and there most likely isn't a general list of roles to use.

Improve this answer
1
  • The question was more whether I need to save an extra employee entity with a foreign key to the login user account or they have the same aggregate root ID. Commented Jan 31, 2024 at 19:03
0

Sooner or later, you're going to create a database. That could be an SQL database, or it could be something you create yourself. But it will have:-

  • A number of tables storing data.
  • A method of querying data in those tables.
  • A persistence system, so you don't lose everything if someone reboots the computer it's running on.

If the user IDs don't match the employee login IDs, then you need an Employee table to link the two. Take their login ID, look it up in the table, and read out the user ID.

In the spirit of "prefer containment over inheritance", an employee is a user who has extra employee data in the table of users. A supervisor is someone who has extra supervisor data. There's nothing stopping someone being both an employee and a supervisor.

Time bookings would be another table in the database. Each entry will contain the ID of the customer (are customers users as well?), and the ID of the employee who did the work. That way you can easily query the table to find all work booked to a customer, or all work done by an employee.

Improve this answer
0

Generally speaking, a "user" is whoever isn't a "developer".

In terms of the concept which is associated with a user's access to and authority within an application, I find it much better to think of "logins" than "users", because you'll often find real users may end up with multiple logins, that a single login may be shared between users, or that logins need to be furnished for automated activity which does not originate with a specific user.

When designing an application, it's best not to bake a permissions structure directly into the core (such as by distinguishing "employees" from "supervisors" as fundamentally different kinds of login), but instead have a separate layer which controls what a particular login is allowed to see, change, or do.

Typically, the only concession the core of the application needs to make to the permissions system, is to ensure there are a sufficient number of different screens to show different levels of information or functionality according to the authority the user has.

If you try and plumb a large number of different display modes into a single screen, which varies what it shows or allows depending on the authority of the login, it can be very difficult to keep it all maintained, and also to communicate effectively about what different people will see or be shown (because the same screen, under the same name or designation, could look very different to different logins).

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.