Using domain driven design entities in an ASP.Net application

Question

I am starting to write a domain driven design application using ASP.Net. This is a relatively new subject to me, and I would like to understand the best practice.

Is it right to use DDD Entity classes as model classes for ASP.Net CRUD operations, or should we define separate POCO classes for that?

In the following example, can Skill be a DDD entity class?

[HttpPost()]
public async Task<Skill?>? SaveSkill(Skill skill)
{
    skillList.Add(skill);

    return await Task.FromResult(skill); ;
}

Both approaches work for me. However, I like to define entity classes with factories and private setters, and this way it did not work because POST required a default parametless constructor.

Answer 1

It depends on what you understand by DDD Entities.

If DDD Entity is driven by UI, it is needed to be mapped to entity, to allow greater flexibility between frontend and backend.

So in that case you should create contract between frontend and backend, which would be your DTO (POCO), that then will be used to persist data in database.

Most probably entity returned for view will also need a mapping.

At early stage of project such mapping seem usually redundant, but over time there are more information added overtime to DTOs, that do not fit into database model.

Side note

Your code incorrectly persists entity, it should contain call DbContext.SaveChangesAsync after adding the entity.