How to design this case in DDD (domain-driven design)?

Question

I have an employee that has to record the time when it starts to work and the time when it finishes.

This records can be associated with a proyect or not. Project could be null.

The proyect has an ID and a proyect number.

The employee gives the proyect number, not the ID of the proyect.

So I was thinking in this code:

//Application service
public class AddApplicationService()
{
    public static async Task<Record> AddStartRecord(long paramEmployeeId, long? paramProjectNumber)
    {
        //I get the employee, it is which has the business logic
        Employee myEmployee = await _employeeRepository.GetEmployeeAsync(paramEmployeeId);

        //I get the project from the project number, to know the ID
        Project? myProject = await _employeeRepository.GetProjectAsync(paramProjectNumber);

        //The employee create the new record. It adds to its records collection.
        Record myNewRecord = myEmployee.CreateRecord(myProject.Id);

        //The repository creates the new record because it is a new entity in the collection of the employee.
        await _employeeRepository.SaveChangesAsync();
    }
}




public class Employee : Entity, IAggregateRoot
{
    public Employee()
    {
        Id = 0;
    }


    public long Id {get; private set; }
    public ICollection<Record> Records { get; private set; } = new HashSet<Record>();




    public Record CreateRecord(long? paramProjectId)
    {
        Record myRecord = new Record(DateTime.Now, paramProjectId);

        this.Records.Add(myRecord);

        return myRecord;
    }
}





public class Record : Entity
{
    public Record(DateTime paramRecordTime, long? paramProjectId)
    {
        Id = 0;
        RecordTime = paramRecordTime;
        ProjectId = paramProjectId;
    }


    public long Id {get; private set; }
    public DateTime RecordTime { get; private set; }
    public long? ProjectId { get; private set; }
}



public class Project : Entity : IAggregateRoot
{
    public long Id {get; private set; }
    public long Number {get; private set; }
}

One of my doubts is about the project entity.

If I am not wrong, it has to be an entity, not a value object, because it has an ID.

But this entity has not business logic, I use it only to get the Id of the project to can be assigned to the record. This makes me think that it is an anemic model. But if not, how to get the Id of the project from the project number given by the user?

I have this problem or consideration because a rule of the domain is that a project doesn't get a number until it is aproved, so it can't be the identitfier of the entity, I have to use an ID, that in the databse is a surrogate key, an autonumeric bigint.

I comment this relation with the database to try to be clear, but I know the domain shouldn't be affected by the persistence, but as I told, in the domain there is a rule that tells the project doesn't get a number until it is aproved.

Also it seems a bit odd to have the entity project, because it is not used as property in the record entity, it uses the id of the project, because one of the common advises in DDD is not to point to the instances of another root entites, but uses the id instead.

There is better ways to design this? I am sure yes, because I am starting with DDD, and I I have the general concepts, but when I have to design a case, it is when I get the doubts.

Thanks so much.

Answer 1

I suggest that you start with clarifying all requirements, you can do so by thinking about the states of the Project over time, and of course within the needs of the system you are creating, and slightly for what changes could be added in the near future.

Quoting "When you think of an Entity, imagine something that needs to be tracked over time and whose attributes are likely to change over time."

Think about the characteristic of a Project, would you need to differentiate projects even if they have same amount of time -Records- and same employees working on them?

If yes:

will you need to add other attributes -characteristic- to to the Project that is related to your requirements?

Then it's an Entity.

Refer back to this blog