I'm working on a project using both domain-driven design and test-driven development. While reading through the DDD book by Evans, I noticed that he did not define interfaces for aggregate roots in the domain.
If I'm doing both DDD and TDD, should I define interfaces for each aggregate root to make the aggregate root classes easily testable and mockable? If so, should I also define interfaces for each entity contained within the aggregate root as well?
From my searches on Google and StackOverflow, I've found answers that come close to what I'm looking for, but I'm specifically look for advice when doing both DDD and TDD because my assumption is that testability, when doing TDD, might be overlooked in the answers that I've seen so far.
No, test directly against the aggregate. The aggregate itself shouldn't have injected dependencies and if a specific behavior requires a dependency, that should usually be expressed as an interface. An interface on an aggregate is a needless abstraction - there is only one implementation of behaviors - that is the point. Also, take a look at BDD and DDD - Behavior-Driven Development can be seen as an evolution of TDD and aligns nicely with DDD.
I'm used to define interfaces for all entities and domain services to ease the test of clients using the domain. Moreover such approach ease AOP when required.
As for value objects, it depends. For example I don't use interfaces for event arguments, identifiers, exceptions (obviously) and some other kind of "contracts". However, I had to introduce interface to ease the isolation of client code testing. Thus my rule of thumbs is: how many step the client require to get the value object in the desired state? If it's more than one (or two, good sense is my friend :-D), I introduce an interface from the very begining.
Note I'm not talking about aggregates, since all my aggregates are entities too.
来源：https://stackoverflow.com/questions/16041804/should-an-aggregate-root-implement-an-interface-in-domain-driven-design