If a federated root implements an interface in domain-driven development

Question

I am working on a project using both domain-driven design and test development. After reading the Evans DDD book, I noticed that it did not define interfaces for the aggregate roots in the domain.

If I do DDD and TDD, do I have to define interfaces for each root node to make aggregate root classes easy to test and prototype? If so, should I also define interfaces for each object contained in the root of the aggregate?

From my searches on Google and StackOverflow, I found answers that are close to what I am looking for, but I specifically seek advice when doing DDD and TDD, because my assumption is that testability when doing TDD might be missed in the answers that I have seen so far.

Answer 1

No, check directly against the totality. The aggregate itself should not introduce dependencies, and if a particular behavior requires a dependency, it should usually be expressed as an interface. An interface on an aggregate is an unnecessary abstraction - there is only one implementation of behavior - that’s the point. Also, check out BDD and DDD - Behavioral development can be seen as an evolution of TDD and goes well with DDD.

Answer 2

I use interfaces for all entities and services of the domain to define, to facilitate verification of clients using the domain. Moreover, this approach makes AOP easier when necessary.

As for value objects, it depends. For example, I do not use interfaces for event arguments, identifiers , exceptions (obviously) and some other “contracts”. However, I had to introduce an interface to facilitate isolation of client code testing. Thus, my rule of thumb is: how many steps does a client need to get an object of value in their desired state? If it's more than one (or two, common sense is my friend: -D), I represent the interface from the very beginning.

Note I am not talking about aggregates, since all my aggregates are also objects.