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; }     string LastName { get; set; }     string Email { get; set; }     Role Role { get; set; } } 

The User Implementation (Implemented into LinqToSql Data Access Layer) :

public class User : IUser {     public string FirstName { get; set; }     public string LastName { get; set; }     public string Email { get; set; }     public Role Role { get; set; } } 

The User Implementation (Implemented into NHibernate Data Access Layer) :

[NHibernate.Mapping.Attributes.Class] public class User : IUser {     [NHibernate.Mapping.Attributes.Property]     public string FirstName { get; set; }      [NHibernate.Mapping.Attributes.Property]     public string LastName { get; set; }      [NHibernate.Mapping.Attributes.Property]     public string Email { get; set; }      [NHibernate.Mapping.Attributes.Property]     public Role Role { get; set; } } 

this only illustrate some DAL specific implementations, don't have a better sample at this time.

Answer 1

My feeling on this is that domain objects (not domain entities, as that title implies something to do with a database) should not be interfaces unless you have a very compelling reason to believe that you will need to support multiple implementations at some point in the future.

Consider that the domain model is the human model. The business/service/document is, literally, the domain. Most of us are developing software for a single business or purpose. If the domain model changes, it is because the business rules have changed, and therefore the old domain model is no longer valid - there is no reason to keep the old one around, running alongside the new one.

The debate is obviously not black-and-white. You might be developing software that is heavily customized at multiple client sites. You might really need to implement different sets of business rules at the same time, and simultaneously have a genuine need to fit them into a unified architecture. But, in my experience at least, these cases are the exception rather than the rule, and although I am not generally fond of the term, this might be a case where you should be thinking to yourself, YAGNI.

Data access is a common area where you want better abstractions (persistence ignorance). In your example, you have NHibernate attributes on your model class. But adding persistence attributes makes it no longer a true domain class because it introduces a dependency on NHibernate. NHibernate and Fluent NHibernate support mapping POCOs using an external mapping declaration instead of attributes on the data class, and this tends to be the preferred approach when using ORMs such as NHibernate or EF4, because it breaks the dependency between persistence model and domain model.

If these mapping methods weren't supported, and you had to use attributes, then I might indeed suggest using interfaces instead, but ORMs today are more sophisticated than that, using reflection and dynamic proxies and method interception to do most of the heavy lifting, so you don't need to create your own abstractions here.

Some types of objects that you would want to expose as interfaces are:

• Repositories, which are responsible for loading/saving domain objects;
• Plugins/extensions to your program;
• View/presenter models, so that different UIs can be plugged in;
• Abstract data types with many implementations (array, list, dictionary, record set, and data table are all sequences AKA IEnumerable);
• Abstract operations with many possible algorithms (sort, search, compare);
• Communication models (same operations over TCP/IP, named pipes, RS-232);
• Anything platform-specific, if you plan to deploy to more than one (Mac/Windows/*nix).

That's by no means a complete list but it should illuminate the basic principle here, which is that the things best-suited to interface abstractions are the things that:

1. Depend on factors that are likely beyond your control;
2. Are likely to change in the future; and
3. Are horizontal features (used in many parts of the app/architecture).

A domain class will be widely used, but does not fit into either of the first two categories; it is not likely to change, and you have almost complete control over the design. Therefore, unless the classes themselves will be taking on indirect dependencies (which is a situation you should try to avoid whenever possible), I would not go through the extra effort of creating an interface for every class in the domain model.

Answer 2

Interfaces are normally considered to be "contracts" and would therefore define behavior. The other major use is for mocking, so that you could provide domain entities that were mock-ups instead of coming from a specific data source (and having dependencies on that source).

For a simple data transfer object, I can't see a lot of use for defining interfaces, but I'm willing to be proven wrong. I'd go with simple objects for this.