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?
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?
