I was just looking at a DDD example that had an interface on nearly every class in the system, including the domain classes. One reason for this is mocking (which I don't favor for the domain anyway) but the other seemed to be to improve the design. This second reason made me think I should disuss why I don't think the "everything needs an interface" approach is a good one for the domain.
First off I should say that the topic has already been discussed.:
I disagree slightly with the two viewpoints, to me you only need abstract classes or interfaces in a minority of cases. In the domain I believe you should only add an abstract class or an interface where you believe that the addition is improving the design, most commonly when it is a useful abstraction.
I do agree with the second view as even when you do have a useful abstraction an interface isn't always enough, you sometimes want to enforce the constraints (bake them in) and an abstract class is better for this.
Having said that I wouldn't take my Customer class and just create an ICustomer interface (or an abstract base class) on it, instead I'd look at the usage of the class and the coupling to it which might lead me to extract meaningful interfaces. In fact in many cases I'll just start out by referring to the concrete Customer domain class, only introducing abstractions where I know they are needed.
In summary only put in interfaces or abstract classes in the domain where they are helping, don't go for what Fowler refers to as "Interface Implementation Pair" approach.
Actually this post sums that up my view nicely.