C#•2y ago

❔ Best Approach to deal with DDD Entities and EF Core Entities

Lets say I want towork on a project using DDD (Domain Driven Design) and EF Core, as you know by following one of the DDD rules, the project should contains a Domain layer which contains the domain Entities... , Lets say in the Domain layer I have these entities :

public class Product : Entity
{
  public string Title { get; set; }
  public decimal Price { get; set; }

  // Constructoor and other behaviours
}

public class Product : Entity
{
  public string Title { get; set; }
  public decimal Price { get; set; }

  // Constructoor and other behaviours
}

public class Order : Entity
{
  public int ProductId { get; set; }
  public byte Quantitiy { get; set }
  public Decimal Total { get; set; }
  
  public Product Product {get; set; }
  
  // Constructoor and other behaviours
}

public class Order : Entity
{
  public int ProductId { get; set; }
  public byte Quantitiy { get; set }
  public Decimal Total { get; set; }
  
  public Product Product {get; set; }
  
  // Constructoor and other behaviours
}

From your experience, what is the best approach or implementation to let the two DDD's Entities and EF Core's Entities meet?

6 Replies

snowy | switching accounts•2y ago

Personally I'd have my domain model decoupled from the database entity. After that you can just map the entities to the domain models. Althought they may, sometimes, look like the same exact classes with different namings. It is what it is. also DDD sucks And that is, if you're pretending to implementing actual logic inside the domain entity. Otherwise, no need to have 2 different classes at all But don't care about ddd pls

Tvde1•2y ago

I don't really understand the question. How can you make the entities meet? If you're talking about converting your DatabaseOrder to your DomainOrder, you can map manually or use tools like Mapperly or Automapper Also what is the "Entity" base class? You should really avoid that

snowy | switching accounts•2y ago

It's probably a class that holds a public int Id { get; set; } and possible some datetime properties for auditing I usually do that in my projects aswell, why are you telling him to avoid that? The most useful one for me is having the AuditableEntity base class that provides some auditing fields such as CreatedAt or UpdatedAt, that way I can intercept these classes upon saving the changes and setting these values.

Tvde1•2y ago

You should be able to pick the id type per entity, as int isn't always the right solution. I do have an IChangeTrackingEntity interface which defines DateTime properties. I'd prefer an interface over a base class

snowy | switching accounts•2y ago

I mean, if you want to do that, you can simply not have a base class for that specific entity. I do find myself to use int for 99% of my entities tho. Never really had or wanted to use anything else. Unless we're talking about composite keys or something similar. So you define properties in your interface? I honestly just saw a base class as a better fitting. But changes nothing. The main diff I suppose is that with an interface you have to declare the members explicit in the class implementing it. I'd rather just have a base class for that.

Accord•2y ago

Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.

Gaming

Programming

❔ Best Approach to deal with DDD Entities and EF Core Entities