Hello ibox..

Without your help i couldn't really get there..

Thank you so much everyone..

Hey there Gil, you really should not create a new User2 Entity in this case. 

This is a much simpler case you should do what I and @Marlies Quaadgras mentioned below.
I even showed you the images were you should implement your solution, it is really not a good idea to create a new entity were it's not demanded by the business.

Cheers,

Hello there,

Actually, his reply is correct.

Employees entity has two different User Identifiers attributes: UserId and ReportsTo (these 2 attributes point to different records from the Users Entity).

He wants to display the name associated to ReportsTo attribute.

Basically:

• UserId attribute joins with User Entity to get the information of the employee user itself
• ReportsTo attribute joins with User2 Entity (he can rename it) to get the information of the user that the employee reports to

If he simply uses the User.Name field, he will basically display the name of the Employee itself, and not the name of the person to whom it reports.

Kind regards,

Rui Barradas

Hey Rui

You are absolutely right in your comment, I didn't notice that a table had 2 attributes of user identifier type, but even so I don't think that we should advice at all to duplicate the user entity. 

Duplicating anything is already considered a bad practice because increases maintainability, leads to spaghetti code, etc. For entities it's even worse (in my opinion), because of  the added burden in memory usage, added AOs, etc, specially when for this propose, seems like the sole propose of the new entity would be to allow for the display of the "Reports To" Name in the table.

I would advise for a better "granularity" of entities and avoid having 2 attributes of user identifier in the same entity. A new entity "Manager" with just manager related attributes (and not necessary all the attribute from a duplicate of User) could be created and a new join could be created with this new entity with the managerId. 

If we are dealing with a very limited number of Managers like 2 or 3 and business wise we don't really expect them to change and we don't have any other plan for the Manager Entity and we really just need it for the table, even creating a new static entity with the managers names and performing the join with that would be better in my option

But this is just my take on it :)

Thank you for the answer and for adding to the discussion :)

Hello again José,

Thank you for giving your inputs :)

As I can see, he's not duplicating the User entity, he's simply using the User entity to do two different joins in the same aggregate, and there's nothing wrong with it. One join for UserId attribute and another join for ReportsTo attribute.

When you do different joins using the same entity in an aggregate, the platform automatically adds a number to distinguish which join are you referring (therefore User_2 entity will be added), but it's just the name of the entity in the aggregate, there won't be a duplication of the entity itself:

And you can also rename it to make the code more readable:

About your data model insights:

"I would advise for a better "granularity" of entities and avoid having 2 attributes of user identifier in the same entity. A new entity "Manager" with just manager related attributes (and not necessary all the attribute from a duplicate of User) could be created and a new join could be created with this new entity with the managerId."

There's nothing wrong with having two User Identifier attributes in the same entity. Also creating a new "Manager" entity would lead to duplicate entities, because most likely you'll have to use the same attributes for this entity as you already have in the Employees entity. Also, what if the "Manager" reports to someone as well? :)
At the end of the day, a Manager is an Employee and it may also report to someone.

"If we are dealing with a very limited number of Managers like 2 or 3 and business wise we don't really expect them to change and we don't have any other plan for the Manager Entity and we really just need it for the table, even creating a new static entity with the managers names and performing the join with that would be better in my option"

To be honest, a Static Entity for this would be a terrible choice :) static entities should be used for pre-defined statuses or any other values that are not expected to change.
Every time a new manager enters the company or someone is promoted to manager, you would have to change your code, update the static entity and deploy this new version into production. This solution wouldn't be scalable for the business growth.

Kind regards,

Rui Barradas

Hello Rui 

You are right once again, I  misinterpreted your advice of creating a second join with the User entity with creating a new entity because of the entity nomenclature.

Sorry for the confusion and thank you for your inputs and advice :)