What is the relationship between Reconstitution Factories and Repositories in DDD?

Question

According to Evans, in DDD we have two types of Factories, one type for object creation and other type for reconstituting stored objects.

a) While Creation factories can exist as Standalone Factory objects or as Factory methods defined on the root of the Aggregates, should Reconstitution Factories exist only as Standalone Factory objects?

b) I assume Reconstitution Factories should only be used/called by repositories, which will delegate object creation to them?

c) Should Reconstitution Factories be defined within a domain layer, even though they will only be used by repositories?

UPDATE:

My questions are purely theoretical in nature, since I only started learning DDD

I assume that your objects are persisted in a RDBMS not in an oo db .

Yes, they are persisted into relational DB

I see them as simple data transition from the DB to a domain object (get the field from result set and put it in the object, without any validation or other logic)

a) If I understand you correctly, you're saying that even if a creation of particular object is complex enough to use a creation factory for it, reconstitution of that same object in most cases isn't as complex as its creation and thus no need for reconstitution factory?

b) And your reasoning why reconstitution is less complex than creation is based on the assumption that objects stored in DB are already in valid state?

Data mapping objects should be in a different layer. The data mapping layer should be unknown to the domain

I agree

c)

I consider "reconstitution factories" as data mappers and they should reside outside the domain.

But according to Evans, factories ( I'm assuming he means both creation and reconstituition factories ) are dealing with domain concepts ( ie they must know something about the internal structure of an entity or Aggregate they are trying to create/reconsititute ) and as such are part of the domain ( even though they don't represent any domain concepts ), while data mappers aren't part of the domain and also don't have any knowledge of object's internal structure?!

thanks

Answer 1

I assume that your objects are persisted in a RDBMS not in an oo db .

Reconstitution of already persisted objects, that should always be in a valid state, is not complex. I see them as simple data transition from the DB to a domain object (get the field from result set and put it in the object, without any validation or other logic) . For simplicity, in my opinion, methods inside the repositories that rebuild an object based on a result set are enough to keep the repository highly cohesive.

If you really want to go the way of reconstitution factories (and if your domain is complex enough to need such objects), maybe you need a proper ORM framework . Data mapping objects should be in a different layer. The data mapping layer should be unknown to the domain. From Martin Fowler's website : "Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers." , link

I consider "reconstitution factories" as data mappers and they should reside outside the domain.