How coupled should a domain model be? Should all aggregate roots be interfaces?

Question

We're finally building a domain model. The domain model includes interfaces for loosely coupling domain objects to persistence. I'm however wondering how coupled the domain model objects should be to each other.

Does Order point to a Customer or to an ICustomer?

This post mentions problems with aggressively de-coupling objects and seems to discourage "going overboard with [interfaces]". I however don't see how I can truly unit test my domain entities unless I can mock the other entities they depend on, which requires loose coupling.

I'm also uncertain about how realistic it is to want a domain model in which pieces could be swapped out.

Answer 1

I don't mind using concrete collaborators in unit tests when the collaborator:

1) Has a comprehensive set of unit tests that clearly specifies its behavior.

2) Isn't difficult to arrange.

3) Doesn't utilize external resources (or break any of these related guidelines).

We do this all the time with framework classes (say, DateTime or string) - unless an aggregate's child is unusually complex, you should be able to trust it too.

Answer 2

The domain model includes interfaces for loosely coupling domain objects to persistence.

The persistence persists your objects. It knows your object in order to persist them. Decoupling the persistence from the model does not give you anything. Any change in the domain will have to be reflected in the persistence layer,

When doing DDD you work with the domain expert to identify the ubiquitous language, which you then represent in code. I have yet to see a domain expert mentioning an interface. Decouple the ARs in your model by identifying the right concepts in your domain. You might have interfaces defined for some domain services, but make sure they are real service providers in your domain and not some concepts you missed.

I'm also uncertain about how realistic it is to want a domain model in which pieces could be swapped out.

You are right, it's not realistic. You might swap the implementation for a certain service provider, but entities in an AR? I don't think so.

Answer 3

When doing DDD you don't want to 'truly decouple entities'. You should start by partitioning your domain model into Aggregates which should be decoupled. Inside Aggregates there is no need to mock anything because an Aggregate should be treated as a 'unit' for unit tests.

Also, moving as much behavior as possible to Value Object will help you make your domain model testable as Value Objects (which are, by definition, immutable) are very easy to test.