Don’t you mean to say “one repository per aggregate” rather than “one repository per-bounded context”?

Aren’t bounded contexts parent containers to aggregates and it’s possible to have more than one repo in a BC provided that there’s not more than one repo per aggregate?

]]>By: Nick Drewhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1853
Nick DrewTue, 08 Sep 2009 13:13:58 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1853I think it's important to recognise that you should tend towards one repository per-bounded context, not one repository per entity.
So, having a ProductRepository make sense, say in a retail domain, where you may also have a SalesTransactionRepository.
CustomerRepository makes sense, say, in an insurance domain, where you may also have a DocumentRepository (including Quotes and Policies).
The tension comes when you need to cross the bounded context.
If the current transaction is a call centre staff member searching for the quotes for a customer, it is entirely possible that I would use a specification pattern:
documentRepository.getQuotes().SelectMany( q.insuredParties).Where( party.partyKey == currentCustomer.customerKey )
However, if the context is finding all insured risks for quote, then I'd expect there to be something available on the repository for such logic:
documentRepository,
documentRepository.InsuredRisksForQuote( QuoteId )
There are some things that are intrinsically part of the business processes of quotes, and should be first class elements of the domain. There are others that facilitate integration, and allow external specification. Defining bounded contexts helps decide when you should focus on one or the otherI think it’s important to recognise that you should tend towards one repository per-bounded context, not one repository per entity.

So, having a ProductRepository make sense, say in a retail domain, where you may also have a SalesTransactionRepository.

CustomerRepository makes sense, say, in an insurance domain, where you may also have a DocumentRepository (including Quotes and Policies).

The tension comes when you need to cross the bounded context.

If the current transaction is a call centre staff member searching for the quotes for a customer, it is entirely possible that I would use a specification pattern:

There are some things that are intrinsically part of the business processes of quotes, and should be first class elements of the domain. There are others that facilitate integration, and allow external specification. Defining bounded contexts helps decide when you should focus on one or the other

]]>By: Nikola Malovichttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1852
Nikola MalovicSat, 05 Sep 2009 06:51:55 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1852I am also in favor of 3rd option due to two main reasons:
1) Ubiquitous language is very important part of DDD.
FindDiscontinuedProducts is expressing a clear business case while FindAll(p=>p.productDiscount>0) does not.
2) Domain logic in examples #1 and #2 could leak out to application\UI layer using the FindAll \ Query methods.In previous example, logic for what discounted product is inside the method, in second example (functions, dictionaries etc.) that logic is kind-a injected outside.
IMHO, most an examples of an IRepository<T> usage I’ve seen on the net usually look more like generic Data Mapper then repository.
I am also in favor of 3rd option due to two main reasons:
1) Ubiquitous language is very important part of DDD.
FindDiscontinuedProducts is expressing a clear business case while FindAll(p=>p.productDiscount>0) does not.
2) Domain logic in examples #1 and #2 could leak out to application\UI layer using the FindAll \ Query methods.In previous example, logic for what discounted product is inside the method, in second example (functions, dictionaries etc.) that logic is kind-a injected outside.

IMHO, most an examples of an IRepository usage I’ve seen on the net usually look more like generic Data Mapper then repository.

]]>By: Nicholas Blumhardthttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1851
Nicholas BlumhardtFri, 04 Sep 2009 07:03:38 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1851@Jimmy I meant within your classifications of Repository types :) @Jimmy I meant within your classifications of Repository types
]]>By: Eystonhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1850
EystonThu, 03 Sep 2009 18:32:11 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1850I guess I'm lazy in that I use ISession as my UoW directly :) I have SM (IoC) manage that but decide I don't like having the session plugged into several things per request. Now I generally try to structure things so that the object that initiates the UoW is the only one that is auto-wired a session and the UoW (session) is passed to any query object that needs it.
I don't know if this is valid, but I see parallels between Controllerless Actions and Query Objects (vs. a standard Controller and Repositories with custom query methods).I guess I’m lazy in that I use ISession as my UoW directly I have SM (IoC) manage that but decide I don’t like having the session plugged into several things per request. Now I generally try to structure things so that the object that initiates the UoW is the only one that is auto-wired a session and the UoW (session) is passed to any query object that needs it.

I don’t know if this is valid, but I see parallels between Controllerless Actions and Query Objects (vs. a standard Controller and Repositories with custom query methods).

]]>By: bogardjhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1849
bogardjThu, 03 Sep 2009 18:13:01 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1849@Eyston
I don't think it should be. How often do you really swap out ORMs, or databases? That's one of those architecture decisions, hard to reverse and needs to be made very early.@Eyston

I don’t think it should be. How often do you really swap out ORMs, or databases? That’s one of those architecture decisions, hard to reverse and needs to be made very early.

]]>By: bogardjhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1848
bogardjThu, 03 Sep 2009 18:11:42 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1848@Nicholas
Nah, that's still Repository! We use encapsulated query methods, but those queries could be HQL, ICriteria, or LINQ.@Nicholas

Nah, that’s still Repository! We use encapsulated query methods, but those queries could be HQL, ICriteria, or LINQ.

]]>By: bogardjhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1847
bogardjThu, 03 Sep 2009 18:10:40 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1847@Eyston
>So do you have the IoC auto wire the session for the Generic Repository Interface?
yeah, and IoC also controls lifetime management. It's not the session directly, but something like UoW.@Eyston

>So do you have the IoC auto wire the session for the Generic Repository Interface?

yeah, and IoC also controls lifetime management. It’s not the session directly, but something like UoW.

]]>By: Eystonhttp://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/#comment-1846
EystonThu, 03 Sep 2009 14:16:02 +0000/blogs/jimmy_bogard/archive/2009/09/02/ddd-repository-implementation-patterns.aspx#comment-1846Not sure why a DAL has to be ORM agnostic. It seems like a lot of work / over engineering for little practical benefit.Not sure why a DAL has to be ORM agnostic. It seems like a lot of work / over engineering for little practical benefit.
]]>