DDD: How to work with entity variations?

Question

Let's say I have an Entity that represents an employee:

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender
    .... (and so on)

Now, imagine I have a website with 2 pages: A home page and a profile page.

On the home page, there will be the name and the gender of the last 10 employees registered. Like this:

David (male)
Frank (male)
Anna (female)
Bob (male)
Lynda (female)

When I click an employee name, I'll be taken to the profile page which will show me every data of the selected employee

Since I just need their names on the home page, it doesn't make sense to load the entire model from the database (I don't need their gender, hair color, etc..., just the names. Imagine if the employee entity had much more data).

How do I handle this situation in DDD? It doesn't look like this is a bounded context problem. Should I create different variations of the entity? For example:

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender

LastEmployee
    First name
    Gender

Answer 1

The problem is that in general, in any application design, that there are 2 kinds of models: a write model and one or more read models. The classic application architecture style merges the two types of models into one and this leads to problems in implementing the models.

The solution is CQRS, more exactly to think in CQRS, that is, when you think about the models that exists, you imagine a write model (the model responsible for state mutations) and one or more read models (the models responsible with reading/displaying/showing the state).

Full CQRS architectures have different databases for the two types of models but you don't have to go this far. You can have a write model, that is, an Aggregate in DDD terms for the Employee, and two read models for the two use cases: the EmployeeDetails and the LastEmployee. If you don't use domain events to keep the two read models in sync with the write model, you can use the same database/table for the write and the read models but have different services for fetching the data.

So, you can have:

1. EmployeeRepository class for the Employee Aggregate, with load/save methods,
2. ListOfEmployeeDetails class for the EmployeeDetails read model, with find/load methods and,
3. ListOfLastEmployee class for the LastEmployee, with find/load methods,

all these classes accessing the same database table/collection.

Please note that this is not quite 100% CQRS, but more of a CQRS-like application.