4

When looking at the post "Should Entities in Domain Driven Design and Entity Framework be the same?" the accepted answer states that domain entities and EF Entities can only be the same when using code first. This so that the entities can remain "pure".

However, because of this inpediment: "Discussion on many-to-Many relationships (without CLR class for join table)" it is not possible to create an order entity with a collection of product entities without specifying a special entity for the association table (orderline entity).

I now see colleagues taking these association tables into their domain entities and i feel that is wrong because it hints towards coping with persistence and not towards being true to the domain. They are not "pure" anymore in my opinion.

Would you say that it is impossible to have the same Domain entities in EF Core because of the association table entities? How can i cope with this in EF Core?

XWIKO
  • 308
  • 4
  • 13

1 Answers1

2

But in a regular/classic Ordering domain there is a need for an orderline (or order-line-item or whatever you want to call it) because you need to store the quantity and the item price along the product ID.

In most DDD examples this item is a Value object from the DDD point of view and an Entity from the Persistence point of view. If you are wondering how a Value object could be an ORM Entity you should read Persisting Value Objects from the book Implementing Domain Driven Design by Vaughn Vernon.

There are, however cases when the Domain model does not fit 100% percent with the Persistence model. In such cases one needs to attach some meta information to the Domain models in order to match the Persistence models. In general you have two options:

  • you can add the metadata to some external files, like XML-files;
    • it has the advantage that it keeps the Domain model agnostic in regard to the persistence but
    • it has the disadvantage that one must remember to change the external files when the Domain model changes
  • you can annotate the Domain models
    • it has the advantage that it is easy to change at the same time the Domain model and the Persistence model by having the information in the same file; it follows the principle: "things that change together stay together" (Common Closure Principle)
    • it has the disadvantage that it pollutes the Domain model with Infrastructure concerns

If I have to choose, I tend to choose to annotate the Domain models, but you should make that decision by yourself.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Thanks for your answer. I guess orderline is indeed a bad example. I was referring to association tables without extra attributes that have no other role than linking 2 foreign keys. My feeling is that they should not be part of a domain model. – XWIKO Mar 15 '18 at 15:11
  • 1
    @Constantin Galbenu, I have upvoted this question as I found it useful. Could you explain how you would use metadata to allow OrderItems to be added to an Order (in the domain model) instead of OrderOrderItems (OrderOrderItems is a junction table between Order and Order Items)? I will then upvote the answer. Thanks. – w0051977 Sep 05 '18 at 19:22