Single Repository or Multiple Repositories?

In a typical business application, a session is started and persisted across several pages. It is commited only when the transaction is complete.

A good example of this is a tax preparation application. Once the session is started, it is persisted through session, cookies, or both. Nothing is written to file, or database, until the entire profile is complete and the refund/return is calculated.

In such an ennvironment, is makes a great deal of sense to work with the structure imposed by domain driven design, and using a single repository to simple commit the session.

However, there are times when this doesn’t translate correctly, even when domain driven design is used.

An example of this is my forum project. While the entities themselves are good targets for domain driven design, I am not sure about the repositories.

The basic structure is that a Category has many Forums, a Forum has many Threads, and a Thread has many posts. There are other things in there, but that’s enough to describe what I want to get across.

If a user has navigated to /Thread/Edit/42, and they have rights to edit it, all I am concerned about is fetching that record and displaying it. On postback, all I want is to be able to save it.

Nothing is persisted across page iterations. The application is only concerned with the thread in question, and doesn’t care about the owning category or forum.

So, the question is this:

Depsite keeping the domain model intact, should I try to find a way to use the CategoryRepository anyway (even though it means a lot more work, and code), or just create a repository for each aggregate, and not just the root? After all, the application only cares about the level it’s currently working at.

I am tempted to use the multiple repository method, but I want to see if anybody has any concrete reasons for me not to. I mean, there is no rule that says if you use domain driven design, you have to use 100% of it is there? Sometimes the lines are grey and you have to make a judgement call. Right?

Thanks!

A good example of this is a tax preparation application. Once the session is started, it is persisted through session, cookies, or both. Nothing is written to file, or database, until the entire profile is complete and the refund/return is calculated.

How do you know this? I could see lots of scenarios where one would want to persist incomplete returns . . .

It was more of an example of how something might be persisted, and not committing, on every action than it was anything else.

But that didn’t answer my question.