Aggregate Roots & Repositories

Question

I'm currently trying to discover the idea behind aggregate roots and their relation to repositories.

Given are the following domain entities:

public class Country {

    public string Name { get; set; }
    public ICollection<City> Cities { get; set; }

}

public class City {

    public string Name { get; set; }

}

I guess I correctly identified Country as an aggregate root for City since in my domain, there shouldn't be any cities that are not located within a country. It should be only possible to add a new city to the data storage via a country and if a country get's deleted, every city inside should be removed too.

Now, how does such a Country Repository might look like? And how does the Country Aggregate Root look like? Is there a CityRepository inside the domain (which would allow me to add a city to the database even if there is no related country!)? And is there a CountryRepository inside the Country (somehow the country needs to populate it's cities? Or is this the job of a repository?)

Answer 1

I think you have the hang of it. In your case where you describe:

since in my domain, there shouldn't be any cities that are not located within a country. It should be only possible to add a new city to the data storage via a country and if a country get's deleted, every city inside should be removed too

You are correct, the country is the aggregate root. Your country entity code is the aggregate root and it is correct! You would not want a city repo. Your country repo does not really change depending on the related value objects (in this case cities) or entities, so in this case your basic crud api would look like:

public class CountryRepo {
    public Country GetCountry(String name);
    public Country SaveCourntry(Country country);
    public void DeleteCourntry(Country country);
    ...etc...
}

To touch on your last question:

And is there a CountryRepository inside the Country (somehow the country needs to populate it's cities? Or is this the job of a repository?)

Your repository will take care of the activity (handling of your entities). Populating cities would be done in the entity by maintaining the collection. You might make a method on your Country entity to add city:

public void AddCity(City city)
{
    this.Cities.Add(city);
}

remove would be similar, then you use your repo to save the country which should take care of persisting the related collection of cities.

Answer 2

The choice of aggregate root isn't based solely on a hierarchical data relationship. If your application may access City directly and perform operations on City without using Country (except, of course, the add and delete operations that you mention), then Country is not the aggregate root for City.