Should an Aggregate Root Implement an Interface in Domain-Driven Design

Question

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 interfa

Answer 1

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.

Answer 2

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.