CODEWITHSUNDEEP
repositorydomain-driven-design
subliminal.one
subliminal.one

Reputation: 59

domain driven design, repositories and mixed entities

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?

Upvotes: 6

Views: 1582

Answers (4)

cuongle
cuongle

Reputation: 75316

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

Upvotes: 14

jgauffin
jgauffin

Reputation: 101166

Well. The whole purpose of the repositories in DDD is to abstract away the data source. If you're user address needs city/region/country to be complete then use those repositories.

The problem with that approach is that the queries will be rather inefficient.

Instead, create a view in the database which loads the user address with all required information (or use your ORM if you have one).

To summarize:

There is nothing in DDD that dictates how you should implement your repositories. DDD is very clear on that the entity loaded from the repository should be complete, no matter how the information is stored in the data source = The repository is just defined as an abstraction layer

Upvotes: 0

guillaume31
guillaume31

Reputation: 14070

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

Upvotes: 1

bstack
bstack

Reputation: 2528

We came across the same issue with ISO currencies and ISO countries in our system. We found that almost every aggregate root we had (and has a corresponding repository for) required currency and/or country entities as a sub entity. This was proving inefficient from a data management and data retrieval perspective so we did the following:

  1. Still maintain the concept of only 1 repository per aggregate root (like Cuong Le's answer above)
  2. Maintain a cache of country and currency data - when an aggregate root is being exhausted from the database, we use the cache to retrieve currency/country information

From my experience DDD and the blue book is an invaluable guide but you dont have to adopt it 100% accurately, you take the recommendations on board but thenyou adapt it to make sense for you.

Hope this helps ...

Upvotes: 0

Related Questions