Should Domain Entities be exposed as Interfaces or as Plain Objects?

Question

Should Domain Entities be exposed as Interfaces or as Plain Objects ?

The User Interface :

public interface IUser
{
    string FirstName { get; set; }
           


        

Answer 1

An entity in most cases should not be typed.

An Entity explicitly defines an identity unique to other entities of the same type. An Order entity should already have an identity that is different from all other Order entities in the system. It can also be damaging to an entity's identity if you model it via inheritance.

For example: Say you have a Customer and you implement Customer as AmericanCustomer. Give it all the behavior and state needed to be an american customer (hint: loves shopping!). Then later that same Customer, with the same name, same shopping habits - travels to Japan. Are they still an AmericanCustomer? Do you create a new JapaneseCustomer and copy all the data including the ID of that customer into this new type? That could have consequences..

Does that same customer still love shopping? That may or may not be true for the JapaneseCustomer. Yet now all of a sudden within a single booked flight this Customer is different. Other objects in the system will request that same Customer using its unique id and may end up with a different picture of the object than they expected (an AmericanCustomer). Maybe the Customer is modeled around national origin instead of current location. That could solve some of the problems, but also introduce new ones.

Model your Entities around their identity. Identity isn't just about ID fields. A model is more than that. Entities should have meaningful behavior in the form of business logic, yes, but they aren't services. You should not be worrying about polymorphically dispatching to different behaviors. What is more important is how your system views this Entity via its unique identity. Avoid thinking about entity types. Organize around identities instead.