DDD: What are good reasons for you to loosely-couple Entities?

Question

Back in December, there was this post that was answered with "it is ok to use concret types [for simple object]".

But I keep seeing more and more simple entities with interfaces in sample projects, and even the very large Enterprise application I just took control over (counting 89 interfaces and going).

Is it that people are not picking the best approach, and just shotgunning the project with the "my project is loosely-coupled!" approach?

Or, am I missing something. I can unit test with concret types for my IService, IFactory and IRepository implmentations I have (and works quite well). I am also building my first "Anticorruption Layer" for abstracting a lot of these 3rd party tools out away from the main domain. This anticorruption layer has a number of Facades, Translators, and Adapters - all of which are loosely coupled (or planned to be).

So, is there something I missing about Entities having Interfaces?

public interface IContent
{
  Int32 ContentID {get; set;}
}

IList<IContent> list = new List();

Edit: I should also mention that that the enterprise app I have that has all of these interfaces, has zero unit tests. lol

Answer 1

It is more important that entities that have responsibility conform to an interface than it is for simple data objects. If you can define the entity in terms of methods, then, yes, you'll benefit from an interface. I can't see that an object that will simply be used as a DTO within the application gains any great advantage by having an interface.

That said, there is certainly benefit from abstracting away "entities" created by a third party tool, or a framework like L2S, in my opinion.