DDD and CRUD on lookup tables using repository pattern

Question

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.

Answer 1

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

Answer 2

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 .

Answer 3

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.