The story about Domain-Driven Design (DDD) continues by introducing a legendary pattern: the Factory.
When I wrote the title of this article, I was trying to remember the first design pattern I had learned from
“The Gang of Four”. I think it was
one of the following: Factory Method,
Decorator. I am sure that other software engineers
have a similar story. When they started learning design patterns, either Factory Method or
Abstract Factory was one of the first
three they encountered. Today, any derivative of the Factory pattern is essential in Domain-Driven Design, and its
purpose remains the same, even after many decades.
We use the Factory pattern for any complex object creation or to isolate the creation process from other business
logic. Having a dedicated place in the code for such scenarios makes it much easier to test separately. In most cases,
when I provide a Factory, it is part of the domain layer, allowing me to use it throughout the application. Below,
you can see a simple example of a Factory.
The Factory pattern goes hand-in-hand with the Specification
pattern. Here, we have a small example with LoanFactory, LoanSpecification, and Loan. LoanFactory represents
the Factory pattern in DDD, and more specifically, the Factory Method. It is responsible for creating and returning
new instances of Loan that can vary depending on the payment period.
As mentioned, we can implement the Factory pattern in many different ways. The most common form, at least for me,
is the Factory Method. In this case, we provide some creational methods to our Factory struct.
In the code snippet from above, LoanFactory is now a concrete implementation of the Factory Method.
It provides two methods for creating instances of the Loan Entity. In this case, we create the same
object, but it can have differences depending on whether the loan is long-term or short-term. The distinctions
between the two cases can be even more complex, and each additional complexity is a new reason for the existence
of this pattern.
In the example above, there is a code snippet with the Abstract Factory pattern. In this case, we want to create
instances of the Investment interface. Since there are multiple implementations of that interface, this seems
like a perfect scenario for implementing the Factory pattern. Both EtfInvestmentFactory and StockInvestmentFactory
create instances of the Investment interface. In our code, we can keep them in a map of InvestmentFactory
interfaces and use them whenever we want to create an Investment from any BankAccount. This is an excellent use
case for the Abstract Factory pattern, as we need to create objects from a wide range of possibilities (and there are
even more different types of investments).
CryptoInvestmentDBFactory is a Factory located within the infrastructure layer, and it is used to reconstruct the
CryptoInvestment Entity. In this example, there is only a method for transforming a DAO to an Entity, but the same
Factory can have a method for transforming an Entity into a DAO as well. Since CryptoInvestmentDBFactory uses
structures from both the infrastructure (CryptoInvestmentGorm) and the domain (CryptoInvestment), it must reside
within the infrastructure layer. This is because we cannot have any dependencies on other layers inside the domain
I always prefer to use UUIDs within the business logic and expose only UUIDs in the API response. However, databases
do not typically support really well strings or binaries as primary keys, so the Factory is the appropriate place to handle
The Factory pattern is a concept rooted in older design patterns from The Gang of Four. It can be implemented as an
Abstract Factory or a Factory Method. We use it in cases when we want to separate the creation logic from other
business logic. Additionally, we can utilize it to transform our Entities to DTOs and vice versa.