Search code examples
domain-driven-designrepositoryrepository-patternunit-of-workddd-repositories

DDD: is that a Unit Of Work?


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?


Solution

  • 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.