Domain Driven Design and the role of the factory class

Question

I\'am unclear as to what the roles and responsibility of the factory class is. I know enough that the factory class should be resposible for the creation of domain objects (agg

Answer 1

Should the factory be calling directly into the repository to get its data or the service library?

I'd say neither, it should be passed the information it needs directly if at all possible.

Where does the factory fit into the following framework: UI > App > Domain > Service > Data

Not sure where this layering is coming from, layers are not fixed in DDD but I'd say you'd be best focussing on this style

UI > App > Domain

Within the Domain you then have multiple types of objects and I'd set rules about the relationships between them:

• Factories should be passed everything they need to do their work, I thus wouldn't have them calling out to other services or repositories in most cases.
• In most cases entities should not contact repositories, instead services (or other upper layers) should be responsible for this work.
• Entities should not call services, services sit on top of the entities/value objects/specifications and co-ordinate them as appropriate.
• Services within the domain are there to co-ordinate, they don't contain significant domain/business behavior.

If the role of the factory class is for object creation then what benefits does the service layer have?

Eric explains this quite well in the book so I'd refer to it, but ultimately its great if you have cross aggregate behavior or behavior that doesn't fit well into one aggregate (e.g. the account example in the book).