3

I have the following domain models:

public class User
{
    public int Id { get; set; }
    public ICollection<Product> Products { get; set; }
}

public class Product
{
    public int Id { get; set; }
    public decimal Price { get; set; }
}

My User entity has a collection of Products, and no Product can be created without an User. I am using EntityFramework Code First approach, which requires me to declare the Foreign Key on my Product entity, thus changing it to:

public class Product
{
    public int Id { get; set; }
    public decimal Price { get; set; }
    public int UserId { get; set; }
}

I dont quite like this because, from the domain point of view, it is not interesting to have the User foreign key shown in my Product entity. This, however, does not bring any harm to me and I can live with it. Please, mind that I am using an ORM to simplify my work, so I am okay with it to an extent.

Is it okay to my domain entities having properties or such things only to satisfy my ORM of choice requirements?

  • The FK can be left out and just have a navigation property or leave both out. The FK still gets created on db but you won't be able to assign users by id using entities. You will need to select out a user to assign it. Also you should use 'virtual icollection' as it's a navigation property. All depends on relationship you are trying to make. – James Jul 31 '14 at 18:12
  • 3
    You're over-thinking things. DDD is about understanding your domain, it's not a blue-print rule book which gets you fired if you violate one or two set-in-stone rules. The UserId FK is perhaps less ideal, and if your ORM supports it, you could make it a private field, but why bother? Life's too short to be worked up about details like this: it's not as if your model is bad: as long as it's the projection of the abstract entity model representing your domain, you're fine. – Frans Bouma Aug 13 '14 at 8:48
  • 2
    You might be interested in this blog post by Vaughn Vernon on modeling domain models with Entity Framework. vaughnvernon.co/?p=879 – Esben Skov Pedersen Oct 13 '14 at 20:23
3

I've heard Vaugn Vernon say about EF that you shouldn't spend time battling EF in order to make it look like a domain model because EF is much more inflexible than other ORMs. So his advise if you want to use EF is to just have a state object behind the scenes which fits EF and then just let your domain model use that for data storage.

  • Can you add a quote (link)? – Jan Doggen Jul 30 '14 at 7:10
  • I can not find it online. He was talking about this at a DDD workshop. – Esben Skov Pedersen Jul 30 '14 at 8:00
2

If you use the fluent mapping API doing:

HasMany(x => x.Products);

Should be sufficient to create the foreign key relationship between User and Product without needed the UserId property to be specified on Product.

Also note that EF can map data to private properties(and use private ctors and setters) so if a detail like that was absolutely unavoidable you should be able avoid exposing that on your domain.

As a side-note (it may just be your example code); if you want to lazy load Products you will need to specify it as virtual or specify it as an include when performing your queries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.