1

So I am trying to follow the Domain Driven Design approach and am not sure how to handle lookup tables that require CRUD operations. Here is a contrived example to demonstrate my question.

Let's say I have a Person class

public class Person
{
    public string Address { get; private set; }
}

My database has a table of People and a table of Addresses. The People table has a column for Address_Id which is a foreign key to the Address table. The obvious idea being you can't add a person record to the People table with an address value that doesn't exist in the Addresses table since there is a foreign key relationship.

In my application, Person is an aggregate root and thus has an associated repository. Using the repository, I load people which also loads the associated address.

My question is how do I do CRUD operations on the Addresses table? Following DDD principles, I don't think I am supposed to create a repository for the Addresses table.

The requirement for my application is that when creating a new Person object, a drop-down list of addresses is presented from which the user will select an address. They are not allowed to hand type addresses, they must pick from one that already exists. Hence, the CRUD operations on the Addresses table. The administrator of the system will need to manage the Addresses lookup table so that the proper selections are presented to a user creating Person objects.

Again, this is a very contrived example and I get that nobody would ever design such a system. It is simply to help illustrate the question.

meyousikmann
  • 163
  • 4
  • 14
  • 1
    Personally, in the example that you have provided, I would create a repository for the Address table. How else is the Administrator going to manage the addresses? In this case the Address entity is not really "Part" of the person. It is an external factor that can be modified or changed outside the aggregate root. Maybe I am misunderstanding, but I would say go for it. Live on the wild side :) – kmacdonald Apr 11 '14 at 03:16
  • That is pretty much where I was headed. It just didn't seem like the right thing to do following DDD, though. – meyousikmann Apr 11 '14 at 11:57
  • Two remarks - 1. Do you need an extra repository layer on top of the one EF provides (`DbSet`)? 2. An EF class model isn't suited to DDD. – Gert Arnold Apr 13 '14 at 17:46
  • @Gert For point 1, I can think of two very specific reasons to put a repository on top of EF; Unit testing and extensibility. I am not so sure I agree with your point 2. That would imply that you can't, or maybe shouldn't use EF with DDD. – meyousikmann Apr 23 '14 at 00:01

3 Answers3

1

IMO, you have two use cases: 1) Saving Person objects, but before 2) listing all available Addresses to be able to select the right one.

So, I would create a AddressRepository, maybe not a CRUD one, but only for fetching entities.

DrSchimke
  • 96
  • 7
0

Are you ever editing or retrieving addresses on their own? The repository is essentially a mapper for a business object to a relational database, it is supposed to encapsulate how the object is persisted so you don't have to worry about it.

If the object is persisted in multiple tables the business logic does not have to know that, so unless you needed to edit Address objects on their own, I wouldn't add a repository for Address.

Have a look at this: Repository Pattern Step by Step Explanation

Community
  • 1
  • 1
NeddySpaghetti
  • 13,187
  • 5
  • 32
  • 61
0

Well, but I guess property string Address should be Address Address.

In that case, when you store a Person on PersonRepository, if some given Address doesn't exists in the underlying store, the whole repository using its tech-specific implementation will create the whole address registry in your Addresses relational table for you.

Also, I guess you'll be using a repository over an existing data mapper - an OR/M -, which should manage this cases easily: it's just about mapping the whole property as a many-to-one assocation.

Actually I believe a repository should store root aggregates like you mention in your own question.

It depends on your own domain. If an address can live alone because it can be associated to 0 or more persons, you should consider adding addresses using a specific AddressRepository, register addresses using it and later you can always associate one to some Person.

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206