8

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.

user2149358
  • 113
  • 1
  • 8
  • 2
    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. – jgauffin Mar 11 '13 at 14:51
  • However, don't mix in questions about domain entities in general since it makes your question ambiguous. Keep it specific or create multiple questions. – jgauffin Mar 11 '13 at 14:53

1 Answers1

10

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.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • 3
    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. – Giacomo Tesio Mar 08 '13 at 22:20
  • 2
    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. – eulerfx Mar 08 '13 at 23:15
  • 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. – Eben Roux Mar 09 '13 at 06:04
  • restructured your answer. I hope you don't mind. – jgauffin Mar 11 '13 at 14:54
  • 1
    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. – Qerim Shahini Sep 14 '14 at 00:15
  • 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? – Riplikash May 19 '16 at 21:22