domain driven design, repositories and mixed entities

Question

Does it violate any domain driven design principals if repositories talk to each other during construction?

Example a user address repository talks to the city/region/country repositories to get data?

Answer 1

It violates Domain Driven Design, I think, repositories should not reference to each other. Also, you should not map 1 : 1 between repository with database table.

This is the concept of Aggregate and AggregateRoot. Example, assume in database has 2 tables:

Order
OrderLine

With relationship 1:n, (Order, OrderLine) is defined as an aggregate because OrderLine cannot live alone without Order. And in this case, Order is the root of this aggregate.

With this, instead of creating two Repositories:

OrderRepository
OrderLineRepository

You just should have only one OrderRepository to take care of the whole aggregate, using cascading load, insert and delete with OrderLine

So in your case, should consider that whether you have address/city/region/country repositories existing or not.

Hope this help

Answer 2

There are several approaches to your problem :

• Keep a tight relationship between the 2 aggregate roots and systematically hydrate the second root's entire aggregate when you hydrate the first root. This requires that the first repository talk to the second, which IMO doesn't break any DDD principle but can be potentially problematic performance wise.

• Link the 2 roots together loosely. This basically means pointing to the referenced root's ID instead of the full instance. Either the client code or the root itself (though some will say the latter is bad practice) will then rehydrate the referenced root from its ID by calling its repository.

• Realize that objects such as City, Region or Country are really (immutable) value objects, don't need an ID and can be referenced directly by any aggregate root or entity without further consequences. This also means no repository for these objects.

Choosing between options 1 and 2 is merely a technical question and will only affect performance and developer comfort. Option 3 is more of a domain choice with possible business impacts. Are City, Region and Country big domain entities that the user will be able to create, modify and delete ? Are there special screens dedicated to those ? These are issues you need to discuss with your domain expert before making a decision.

Links you might find helpful :

Aggregate Root references other aggregate roots

http://tech.groups.yahoo.com/group/domaindrivendesign/message/8696