This is a simple example to show a situation that I find hard to solve with DDD.

Consider this: - A property (e.g. a house) has an Address. - An address can be complete or partial (country only; country and state; country, state and city). - When a end-user is searching for properties, I need to display a list of all countries. - When a country is selected, I need to retrieve all related states. - When a state is selected, I need to retrieve all related cities.

This can be easily done using a data driven approach (querying against a relational model), but when I try to model this, thinking in Domain Driven Design, I'm failing.

I have this obvious constraints:

  • A city can't exist without a estate.
  • A estate can't exist without a country.

Conclusion - country is the aggregate root to enforce this constraints.

I'm supposing that address is another aggregate root. But address can only refer to an aggregate root, so how can I refer a partial address? Do I need to think in another root? When I need to query for city, I need to bring the whole country aggregate root? And what if I need to search for all cities available for a given string? I need to query for all countries and than transverse through relations?

In this situation, the most obvious solution for me is to have and aggregate root for city, state, country and address. But this is an anemic model. But to avoid an anemic model, it looks like the only way to solve is having different models. One to insert new cities (using the country aggregate) and others to retrieve and associate those entities. But this smells bad.

I'ts very hard to find a sample that cover a situation like this. Can someone give me some directions? I'ts fine to recommend a book, but I would love some direct insights.

I read a lot about DDD and I know most of the terms (aggregate, entities, services, associations, value-objects).

  • 2
    DDD is not a programming methodology; it is a design methodology. You're still going to need to write code to implement the design. Commented Feb 22, 2015 at 15:44

2 Answers 2


Object-oriented modeling, especially in context of DDD is all about behavior. You are talking about anemic model, but I'm having hard time figuring out what behavior would country/state/city have. Mostly, they are just holders of data.

There is also a conflict in your narrative. You are saying the user can get a country or state and based on this, get the data on lower hierarchy. You cannot do this if country and state don't have identity to be identified with, meaning they have to be entities.

In your case, I wouldn't mind creating each of those as an entity. You could also create a composite key for each. For example city key would be composed of {country_id, state_id, city_id}. You can also enforce this by only allowing to "add" new state through country and new city through state. They could create the "containing" part of the key while leaving the child ID to database engine.

  • I'ts been a while since I wrote this question. And yes, I did exactly what you said. Created City, State and Country as entities. Sometimes an anemic model is the answer.
    – Juliano
    Commented Apr 27, 2015 at 16:25
  • @Juliano To be clear, the term "Value Object" is not used to suggest an object does not have an identity. Rather, that the object's identity is its value(s). An Address is the classic example of this, but City and State could be modeled as value objects as well. For example if one changed the {name, lat, lng} of a City would it continue to be the same city? The point I'm trying to make above is that the choice of whether to model a particular set of data as a VO or Entity is not about identity per se. It's about that object's intended behavior! Commented May 2, 2019 at 21:01

You have a good model for handling addresses. The country state(/province) relationship has worked well for me. I am not sure it works for all countries. For the applications I have worked with, I have been unable to normalize the city field. This results in three tables with cascading foreign key constraints.


Searching gets complicated in your case, as you likely want to match cases where only the country or country+state are provided when searching by city. If you can't normalize city, lookups by city will also be difficult.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.