DDD - How to implement factories [closed]

Question

I would like to know how to implement factories in domain driven design. (examples)

Where should be placed interfaces and implementations of factories ? Do I need to create interfaces for Domain objects which factories creating ? Do I need to create factories for repositories, services, ...

I am using Dependency Injection Containers how can I put them together with factories ?

Thanks.

Ilium

imho this question is wrongfully closed since talking about factories in DDD limits it quite well compared to talking about factories in general. how to imlement them is a good question since there are typically three approaches: seperate factories, letting the repositories act as factories or just new the domain entities. – Acaricide

However, don't mix in questions about domain entities in general since it makes your question ambiguous. Keep it specific or create multiple questions. – Acaricide

Answer 1

Factories should be simple classes, usually static. They can also be implemented as static methods on the entity or value object they create. Factories should create domain objects directly and only domain objects. Moreover, factories should not be tied with dependency injection because domain objects shouldn't have dependencies injected into them.

Domain objects should not implement interfaces - that is a needless abstraction.

Services and repository implementations on the other hand do have dependencies and should be created by the DI container.

Influence

Interfaces are actually a needless abstraction if you work alone to develop a disposable prototype (no evolution expected and thus no tests). On complex domains with a large team of people working at different layers, interfaces allow an effective parallelization of refactorings after domain's changes. Moreover, without interfaces, a proper unit testing becomes much harder. – Maje

For domain objects in particular, interfaces are not only a needless abstraction they are a harmful abstraction. Interfaces for services or repositories on the other hand are certainly valuable. However, declaring interfaces for testing alone can be avoided with a nice mocking framework. Generally, I only wish to highlight to cost of abstraction. First, one learns the value of abstraction, then the cost. – Influence

I would agree that in most cases typical domain objects would not need interfaces other than those you mention. But as always it depends on the domain :) If there are generic objects that can be interchanged (strategies) in your domain then it may be useful or even necessary. But I guess it would be an exception. – Piddock

restructured your answer. I hope you don't mind. – Acaricide

There is nothing wrong with a factory (proper factory alla GOF, not factory methods), having dependencies injected into it if it is required to be able to create your aggregates. You might decide to inject a repo into the factory if you need values provided by the repo to be able to construct your aggregate. Same goes for services etc. – Calore

I'm sorry, You've really confused me. Domain objects shouldn't be injected into? So, I need to clarify, do you consider a Domain Service to be a Domain Object? I know some do. I would consider the ability to inject into Domain Services to be very important. But even for Aggregate Rots there are certainly man domains where injection makes sense. The same is true of interfaces. It shouldn't be the default, as many use it, but it absolutely makes sense in many domains. Why do you feel the domain should not have dependencies injected into it? – Irreligion