DDD and implementing persistence

Question

I am getting my feet wet with DDD (in .Net) for the first time, as I am re-architecting some core components of a legacy enterprise application.

Something I want to clear up is, how do we implement persistence in a proper DDD architecture?

I realize that the domains themselves are persistence ignorant, and should be designed using the "ubiquitous language" and certainly not forced into the constraints of the DAC of the month or even the physical database.

Am I correct that the Repository Interfaces live within the Domain assembly, but the Respository Implementations exist within the persistence layer? The persistence layer contains a reference to the Domain layer, never vice versa?

Where are my actual repository methods (CRUD) being called from?

Answer 1

Am I correct that the Repository Interfaces live within the Domain assembly, but the Repository Implementations exist within the persistence layer? The persistence layer contains a reference to the Domain layer, never vice versa?

Yes, this is a very good approach.

Where are my actual repository methods (CRUD) being called from?

It might be a good idea to not think in CRUD terms because it is too data-centric and may lead you into Generic Repository Trap. Repository helps to manage middle and the end of life for domain objects. Factories are often responsible for beginning. Keep in mind that when the object is restored from the database it is in its midlife stage from DDD perspective. This is how the code can look like:

// beginning 
Customer preferredCustomer = CustomerFactory.CreatePreferred();
customersRepository.Add(preferredCustomer);

// middle life
IList<Customer> valuedCustomers = customersRepository.FindPrefered();

// end life
customersRepository.Archive(customer);

You can call this code directly from you application. It maybe worth downloading and looking at Evan's DDD Sample. Unit of Work pattern is usually employed to deal with transactions and abstracting your ORM of choice.