To understand the factory method, let's look into another pattern that has similar motivations, but which is realized differently. Factory methods define factories that are implemented as methods on specific types. There is no single class responsible for creating certain instances; rather, the creation becomes the responsibility of the factory method which is defined as part of a domain class.

For example, let's consider a car that uses its recorded trips to generate a driver's logbook. It perfectly makes sense to include a createDriverLog() method in the car type which returns a logbook value type, since the class itself can provide the logic in a self-sufficient manner. These solutions would be implemented purely in Java without any frameworks or annotations required:

public class Car {

    ...

    public LogBook createDriverLog() {
        // create logbook statement
    }
}

As we will see later in this chapter, Domain-Driven Design factories don't distinguish between abstract factories and factory methods. They are more directed toward the motivations of the domain. In some cases, it makes sense to encapsulate factories as methods together with other responsibilities of a class. In other cases, where creation logic is that particular, single points of responsibility in form of separate classes are more appropriate. Generally speaking, putting the creation logic into domain types is desirable since it may make use of other functionalities and properties of that domain class.

Let's have a look at CDI producers. Producers are defined as methods or fields that are used dynamically to look up and inject instances of certain types. We have full flexibility of what values a field contains or a method returns, respectively. We can equally specify qualifiers to ensure that the producers don't collide with other potentially produced types. The beans that defines the producer method can also contain further properties that is used in the producer:

import javax.enterprise.inject.Produces;

public class BMWCarManufacturer {

    ...

    @Produces
    @BMW
    public GermanCar manufactureCar() {
        // use properties
        ...
    }
}

This matches the idea of factory methods implemented as CDI producers.

The scope of the produced instances needs to be considered. As any other CDI managed bean, the producers are by default dependent scoped. The scope defines the life cycle of managed beans and how they are injected. It affects how often the producer method will be invoked. For the default scope, the method is invoked once per injected instance when the calling managed bean is instantiated. Every time the bean that injects the produced value is injected, the producer method will be called. If that bean has a longer lifetime, the producer method won't be invoked again for that duration.

Later in this chapter, we will see more sophisticated usages of CDI producers.