Value Object Repositories

Dec 22, 2011 at 8:19 PM

Hello Tim,

First of all, thanks for this great book. It's a really pragmatic approach to the DDD concept and this makes it great for understanding it.

I'm only in chapter 3 and halfway through the demo project code, so forgive if my question is already answered, but I couldn't find a helpful answer to it so far.

I'm in the situation where I need aggregated data from the database for logic and presentation. My first thought was to use Value Objects (VO's). However following the style of your demo project VO's (like Address) don't inherit from IAggregateRoot, making the SqlCeRepositoryBase unusable. Also the "default" methods like FindAll, FindBy aren't useful, as my queries aren't static.

A Google search brought me to CQRS (, but this is quite complex, to me as well as my project. However what I do like is separating the Commands (Domain) from the Queries (DTO/VO).

  • Any thoughts on this on how this scenario would fit in style with your demo project?
  • Does this just mean the generic repository is not applicable?
  • Should I create a separate Query library with a repository and service containing the queries?
  • Would allowing the Model/Domain library to ask questions on the Query library be okay from a coupling point-of-view?

Thank you for your answer.

Best regards,


Dec 27, 2011 at 4:43 AM

Hi Peter, thanks for purchasing my book!

Great question!  I struggled with this quite a bit myself.  The way I handled this in the demo project was to put methods that returned collections of value objects into the most closely related aggregate's repository interface. 

For example, IProjectRepository has the following method:  public IList<MarketSegment> FindAllMarketSegments().  This data is needed in the UI layer to bind to a drop down list.  It doesn't really fit the pattern exactly, but I also had to be practical, so that's just how I decided to implement this type of behavior.

To answer your question about the generic repository not being applicable, that is exactly right in this case.  As far as allowing the domain model to ask questions to the query library, I think it is fine as long as it is talking to an abstract type, such as an interface, as opposed to a concrete repository class.  I think that the domain model should know about the repository *interfaces*, that is one of their main purposes.

As far as creating a separate query library, that is up to you and your domian model implementation.  You could probably come up with some interesting uses of LINQ and/or the specification pattern with that.  I chose not to do that here, but just put those extraneous methods on the most closely related repository interface I could find.



Jan 4, 2012 at 4:32 PM

Hello Tim,

First of all, the best wishes for the new year! This year maybe a new edition of the book using EF4? ;)

Just to let you know: Your "closely related" approach works great. I've tested it with a couple of scenario's and it's perfectly managable.