DDD repository and factory

14
votes

In my application a few layers. In this topic will focus on Domain and Infrastructure layers.

I have repository interface ClientRepositoryInterface in Domain layer. And I have implementation of this interface ClientRepositoryImpl in Infrastructure layer.

But to reconstitute the object in the middle of the cycle of its existence I need factory(ReconstitutionClientFactory). Call the factory will be in the repository. The book by Eric Evans is described as a normal practice.

But where this factory(ReconstitutionClientFactory) should be located? In Domain or in Infrastructure layer?

I think in Domain... BUT! But then the lower layer will directly call a higher layer! This is wrong, but how to do right?

2
domain-driven-designrepository-patternfactory-patternddd-repositories
In DDD, both the concepts of "Repository" and "Factory" belong to the domain model, and therefore to the domain layer. They can use components from infrastructure, but they themselves (interface and implementation) are solely part of the domain. Infrastructure must be free of application- and domain-specific details. – Rogério

2 Answers

37
votes

Factory & Repository Concepts

To answer your question, I think it's important to focus on responsibilities of the concepts defined by DDD.

In the blue book, there is a section that deals with the problem that you describe:

A FACTORY handles the beginning of an object’s life; a REPOSITORY helps manage the middle and the end.

and specifically for your question:

Because the REPOSITORY is, in this case, creating objects based on data, many people consider the REPOSITORY to be a FACTORY—indeed it is, from a technical point of view.

(both quotes from Evans, chapter 6, section "The relationship with factories")

To keep the concepts pure, it is important that the interface of your factories and repositories are clean. So don't allow creating new business objects through the repository interface, and don't allow querying existing ones through the factory interface.

Keeping the interfaces clean does however not mean that you should not use a factory from the repository implementation, because, after all, the repository creates an instance at some point, and if that instance creation is complex, a factory is the appropriate solution.

To quote Evans again:

Whenever there is exposed complexity in reconstituting an object from another medium, the FACTORY is a good option.

Note, however, that the repository will most likely call a different method on the factory than the clients that really want to create a new domain object (as opposed to reconstitution).

There is even an example in Evans' book that illustrates approach:

Domain object reconstitution with help of a factory

Answer to your question

Now that it is clear that this is allowed, lets focus on your question of where to put the factory:

The DDD factory interface belongs in the domain, because your domain logic uses this to create domain objects.

The DDD reconstitution factory interface does not belong in the domain, since this is only relevant for your repository. It does not exist in the real world of your domain.

Now if you're using an architecture that prohibits dependencies from the domain to the infrastructure (which you probably should when applying DDD), it's clear that the factory implementation belongs in the infrastructure. Note that it does not matter whether you call your layers layers, rings, realms or whatever, the dependencies are the important part.

16
votes

First of all, the layers approach is kinda obsolete. When talking layers think 'context', who's on top of who isn't important.

The repository is in charge of restoring an object. A factory just creates a new object. Note the different semantics. The repository knows how saving/restoring to/from persistence is done and that depends on the storage and the method of access.

So, everything is done inside the repository i.e in the Infrastructure. If you serialize things, then you need just to deserialize back (this is how a document db does things anyway). If you're using an ORM or store things in tables then you'll do all the query required to get the data and repopulate the object. An ORM is the easiest way since it can use reflection to populate private properties. In this case the ORM itself is the factory.

One more thing, restoring, while technically can be done by a domain factory, it isn't the factory's purpose to do that because it breaks the layer boundaries. We want to keep everything persistence related in the Infrastructure.