I'm trying to apply DDD principles to an application built on top of Doctrine 2.1. To abstract the storage details, I'm using Repositories for my Aggregate Roots, with a strong Contract with the domain. These repositories hide all the implementation details and have to be the only way we can store or retrieve aggregates.
I need to create a class which will be the only entry point to the storage, and which will only have these methods:
class X
{
public function getRepository($className) {}
public function beginTransaction() {}
public function rollback() {}
public function commit() {}
}
Unit Of Work has many definitions, and while some people think about it as just a way to abstract your transaction, others seem to consider it a quite low-level object knowing a lot of details about your domain objects (the Fowler definition is maybe closer to that).
So, is my class X
a Unit Of Work, or does this pattern have another name?
Yes, your class X is a Unit Of Work. Unit Of Work responsibilities are usually implemented by ORM but I think that there is an advantage in wrapping it into your own Unit Of Work class. So that your application code does not have a reference to ORM making it harder to bypass Unit Of Work and Repositories.