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

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?

I disagree here, let's say a system is comprised of the following layers:

• Presentation Layer (win forms, web forms, asp.net MVC, WPF, php, qt, java, , ios, android, etc.)
• Business Layer (sometimes called managers or services, logic goes here)
• Resource Access Layer (manually or ORM)
• Resource/Storage (RDBMS, NoSQL, etc.)

The assumption here is that the higher you are the more volatile the layer is (highest being presentation and lowest being resource/storage). It is because of this that you don't want the resource access layer referencing the business layer, it is the other way around! The business layer references the resource access layer, you call DOWN not UP!

You put the interfaces/contracts in their own assembly instead, they have no purpose in the business layer at all.

Answer 2

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.

Answer 3

Check out what Steve Bohlen has to say on the subject. The code for the presentation can be found here.

I was at the presentation and found the information on how to model repositories good.