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?