DDD and domain interfaces/classes

1
votes

In my application I have an assembly - MyApplication.Core which contains all of my domain objects - Customer, Order etc, as well as interfaces for repositories - ICustomerRepository, IOrderRepository

I have another assembly - MyApplication.Data which contains concrete implementations of those interfaces - OrderRepository etc. The repositories are responsible for retrieving data from the DB and presenting it using the domain objects.

One thing I'm not sure about is whether my domain objects should be classes or interfaces. Would it make more sense for me to define interfaces like ICustomer, IOrder in my Core assembly, and then have the Data assembly provide the concrete implementations? From what I've read so far, it seems that actual classes are recommended, what is the reason behind this?

1
model-view-controllerdomain-driven-design
You would use Interfaces in the same contexts as you would ordinary, non-DDD development. If you want an implementation, you need a class. - Robert Harvey
I often also struggle with knowing when to use interfaces in non-DDD development :) I'm pretty sure I have the general idea, but in this case I cannot see why the repositories should be defined as interfaces but the domain objects should not. I suppose that might be because domain objects can have methods on them which act on their data, and if I was using interfaces I would have to manually implement those methods every time. - NoPyGod
Generally speaking, repositories are places where you can change out the underlying implementation (i.e. with a mock object) for testing purposes. For that, you need an interface. - Robert Harvey

1 Answers

4
votes

Your Aggregates, Entities and Value objects don't need to be defined as interfaces because you should not be trying to avoiding coupling other code to them. Every layer in the Onion Architecture is allowed to have a direct dependency on your Core/Model. Another good rule of thumb is that it is hard to imagine an alternative implementation of the Customer for example.

Repositories on the other hand are usually defined as interfaces so that the code that uses them does not get a dependency on ORM (or data access libraries) that you use to implement a repository.

Speaking of interfaces outside DDD context, I find this article by Mark Seemann very useful: Interfaces are not abstractions.

Would it make more sense for me to define interfaces like ICustomer, IOrder in my Core assembly, and then have the Data assembly provide the concrete implementations?

This may be a sign that your domain objects are really data objects and the design suffers from the AnemicDomainModel anti-pattern. Why would Data assembly contain implementation of the business logic?