Comments on: DDD: Repository Implementation Patterns

By: matt kocaj

matt kocaj — Fri, 11 Feb 2011 05:49:04 +0000

@Nick Drew,

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 Drew

Nick Drew — Tue, 08 Sep 2009 13:13:58 +0000

I 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 other

By: Nikola Malovic

Nikola Malovic — Sat, 05 Sep 2009 06:51:55 +0000

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 Blumhardt

Nicholas Blumhardt — Fri, 04 Sep 2009 07:03:38 +0000

@Jimmy I meant within your classifications of Repository types

By: Eyston

Eyston — Thu, 03 Sep 2009 18:32:11 +0000

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: bogardj

bogardj — Thu, 03 Sep 2009 18:13:01 +0000

@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: bogardj

bogardj — Thu, 03 Sep 2009 18:11:42 +0000

@Nicholas

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

By: bogardj

bogardj — Thu, 03 Sep 2009 18:10:40 +0000

@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: Eyston

Eyston — Thu, 03 Sep 2009 14:16:02 +0000

Not sure why a DAL has to be ORM agnostic. It seems like a lot of work / over engineering for little practical benefit.

By: Daniel

Daniel — Thu, 03 Sep 2009 12:57:56 +0000

I’ll need to try this again, but last time I played with creating a Generic Repository, I was a little frustrated. Since ORMs then didn’t support POCOs, and each has its own flavor of attributes/mapping/etc., it ended up that the entity (ie Customer) was tightly coupled to one specific repository implementation (ie LinqToSqlRespository). Creating, say, a EntityFrameworkRepository or NHibernateRepository would mean also changing the entity.