Struggling with DDD, Repository Pattern, and Associated Domain Models...

Question

I'm really struggling to wrap my head around some of this stuff. Let me give an example of where I'm struggling.

I'm using Linq-2-Sql as the DAL for my app and the IRepository pattern used in the MVC Storefront sample app from Rob Conery.

In my domain I have a Customer Model which has a collection of Address Models. In my UI there is a button which allows the user to add a new address to the customer. This opens up an address editor which let's them fill in all the information.

What happens next? Does the address get saved to the database, then added to the list in my customer object? Does it just get added to the list but not updated until the Customer object get's saved? What if the user wants to delete an address? Do I delete the address in the database and then remove it from the list? Or do they just make all the deletes/adds they want and I dump everything from the database everytime and update it with whatever is in the Customer.Addresses collection? What's the right flow here?

Should the collection of addresses only get updated via the Repository by calling something like this:

public void AddAddressToCustomer(Customer c, Address a)
{
    //validate and save address to db
    //add the newly saved address to the Customer Object
}

Help...

Answer 1

DDD is an area where I have a lot of interest but but very little experience so please treat my suggestions cautiously. I only offer them because of the absence of other, more authoritative, answers.

In 'the book' by Eric Evans address is given as an example of something that should typically be treated as a Value Object rather than as an Entity. So I believe the Add method would belong to the Customer:

customer.Add(address);

There would be a Customer Repository (but not one for addresses). This might be used like this:

customerRepository.Update(customer);

The intentional affect of this is that all the difficult questions you ask about how this is then implemented at the DB layer are not the concern of the domain objects (i.e. the customer object). I'm afraid I can't help beyond that point either.

Answer 2

Sounds like you don't know the context of your domain as well as you need to. Ask some more questions and get a better user story. Potentially any of your proposed scenarios may meet the business need, depending on what it is. When you understand the need then I believe this issue will iron itself out.

Answer 3

it depends had a great start on the answer. Once you add the address to the customer and save the customer using:

customer.Add(address);
customerRepository.Update(customer);

Your repository would then map your customer and address domain layer entities to LINQ to SQL. This will likely involve creating a new DataContext object, getting the related LINQ to SQL entities (or creating new ones) and then mapping the domain layer entities to your LINQ to SQL entities.

var context = new MyDataContext();
var linqCustomer = MapCustomerToLinqCustomer(context, customer);
var linqAddress = MapAddressToLinqAddress(context, customer.Addresses.First());
context.SubmitChanges();

You could also use DataMapper classes for mapping, but the MapXYZ methods more closely follow Rob Conery's example. If you need more help with the MapXYZ methods, let me know.