Refactoring from Active Record to Repository

In the begining of our project, we started with a Repository like pattern for retrieving our entity objects. Our repositories were muddled, and at times, contained a lot of our business logic. We followed the basic pattern to create a repository for each entity object. It produced a lot of duplication because many repositories shared many very similar operations. The result was a confusing system, and made retrieving entity objects harder than it has to be. We decided to refactor to Active Record because we thought that will solve all our problems.

Active Record pattern made testing harder because static methods can not be polymorphic. Recently, we are leaning more towards repository pattern again, but we want to design it right this time. Repository will definitely alleviate testing. On top that, it will also allow us to cache data in a simple and centralized manner.

One thing that is not clear to us is which entity object receives a repository. Ideally, we do not want to create a repository for every entity in our system. In Domain-Driven Design by Eric Evan, he talks about using Aggregate to eliminate the need for creating a repository for each entity object. Aggregate is a group of associated objects that will be treated as a single unit. The root aggregate is an object that will encapsulate all associated objects. The client will have to retrieve the root in order to communicate with any objects inside of the root. Only entity objects will receive a repository is the root.

I think we are on the right path, but more disscusion is required to fully understand the implication of moving toward a full blown repository pattern.