Is using one-to-one interfaces with domain entities a good or bad practice? Why?

Question

One thing I see in some DDD enterprise apps that I work on, is the use of interfaces that are identical to the domain entities, with a one-to-one mapping of properties and functions. Indeed a domain object is always used through it's one-to-one interface, and all domain entities have a one-to-one interface in this style.

For example:

Domain object Account:

public class Account : IAccount
{
     public string Name {get;set;}
     //...some more fields that are also in IAccount
     public decimal Balance {get;set;}
}

And it's matching interface

public interface IAccount
{
   string Name {get;set;}
   //... all the fields in Account
   decimal Balance {get;set;}
}

But lately I've become increasingly convinced that this is, in fact, an anti-pattern.
I ran it by some architects in the open source community, and they say that this is based on design mistakes or flaws, somewhere up the chain of design.

So I tell my colleagues that they should quit creating interfaces for the Domain objects. Because there is no purpose to them, and you have to update the interface whenever you update the domain entities.

First the claim was made that these interfaces provide 'decoupling', but I counter that because the interfaces have a one-to-one relationship with the domain entities that they do not really provide any decoupling, a change to the interface means a change in the domain entity and vice-versa.

The next claim is that we need the interfaces for testing purposes. My counter is that Rhino-mocks provides for the mocking and stubbing of concrete classes. But they claim that Rhino-mocks has trouble with concrete classes. I don't know if I buy that, even if rhino-mocks has trouble with concrete classes, that doesn't necessarily mean we should use interfaces for the domain entities.

So I'm curious:

Why would you have one-to-one interfaces for your domain entities?

Why not?

Why is it a good or bad practice?

Thanks for reading!

EDIT: I should note that I use interfaces all the time, and I believe that if it's called for I will use an interface at the drop of a hat. But I'm specifically referring to domain entities with one-to-one interfaces.

Answer 1

It's a bad practice as described, but...

There's no specific reason that your interfaces need to be different than your domain entities; sometimes it really is the right mapping. But it's suspicious that it's always the case. The point of concern there is a question of whether or not the interfaces were truly designed, or whether they were just thrown into place out of lack of time / laziness.

To use your example, the IAccount interface you describe exposes getters and setters on the Account object; it seems a little odd and unlikely that everything that uses an Account will have a need to set the balance on the account, and that that implied permission is specified at that level of interface. Is there no place in your system where you want to merely check but not set the Account balance?

Answer 2

The biggest reason for always specifying the domain objects as interfaces instead of directly as classes is to give you a degree of freedom on the implementation. In your example you only have one kind of IAccount, so it's a little redunant.

But what if you had, for example:

public class Account : IAccount { ... }       // Usual account, persistent
public class MockAccount : IAccount { ... }   // Test mock object
public class TransAccount : IAccount { ... }  // Account, not persistent
public class SimAccount : IAccount { ... }    // Account in a performance sim

and so on?

By defining the domain objects as interfaces, you can replace the implementations without disturbing your domain definition.

Answer 3

In general, if my classes are not going to be part of a design pattern like Strategy or Visitor I don't add interfaces.

Adding interfaces is really useful for design patterns like Strategy and Visitor, but in those cases I don't carbon copy the getters and setters of the domain classes. Instead, I create interfaces that are specific for the design pattern interfaces I create.

interface SomeStrategy {
   void doSomething(StrategyData data);
}

interface StrategyData {
   String getProperty1();

   String getProperty2();
}

That allows me to let the domain classes implement those interfaces, or to use the Adaptor pattern. I find this is a much cleaner approach that just creating interfaces for the sake of it.

Design should always reduce uncertainty. Creating interfaces for the sake of it doesn't reduce uncertainty, in fact it probably increases confusion since it doesn't make any sense.

Answer 4

How do you want to handle data transfer between your business objects down to you data access layer?

Assume we have the following namespaces, Sample.DataAccess and Sample.Business. Then we would have the following.

// in namespace Sample.Business
public class Account : Sample.DataAccess.IAccount
{
     public string Name {get;set;}
     //...some more fields that are also in IAccount
     public decimal Balance {get;set;}
}

// in namespace Sample.DataAccess
public interface IAccount
{
   string Name {get;set;}
   //... all the fields in Account
   decimal Balance {get;set;}
}

How do you handle your business objects in the data access layer without including a reference to Sample.Business (which is bad because your Business objects are already going to have a reference to Sample.DataAccess)

This is what I have seen done.

// in namespace Sample.DataAccess
public class AccountDA
{
   public AccountDA()
   {
   }

   public int SaveAccount(IAccount account)
   {
      //access the elements and set them in their
      //parameters for a stored proc.
      //otherwise handle in your ORM
   }
}

Answer 5

One-to-One Interfaces on entities are an anti-pattern

James Gregory put it better than me here.