Manual instantiation vs CDI for dependency management

[aureamunoz]

Right now, our code creates and wires services manually (moreover not for all services)
Each service is instantiated explicitly, and its dependencies are passed through the constructor. Most of these fields are declared as final, which lets us use immutable objects or even records in some cases. This approach has worked fine so far — it keeps things simple and predictable.

However, as we continue to evolve the PoC, we should probably revisit whether it makes sense to adopt CDI for dependency injection instead of doing it manually.

A few points worth discussing:

Current approach (manual instantiation)

• Keeps objects immutable (final fields, possible use of records).
• Clear visibility of dependencies in constructors.
• No container lifecycle overhead.
• Easy to reason about for a small PoC.

What switching to CDI would involve

• Turning services into CDI beans (@ApplicationScoped, @Dependent, etc.).
• Removing some final fields or replacing records with regular classes (since CDI manages lifecycle and may need proxies).
• Letting Quarkus create and inject dependencies automatically.

Points to reflect on

• For now, our manual setup works well and keeps the PoC lightweight.
• If the project grows, CDI could simplify wiring and configuration management.
• CDI would also make it easier to use interceptors, scopes, metrics, and configuration injection.
• On the other hand, we’d lose some immutability and control over object creation.

There are still a few services that rely on static methods. While using static methods can simplify certain things, it also breaks many of the benefits of object-oriented design and CDI.
Once we agree on whether we want to stick with manual instantiation or move to CDI, we should also revisit those static services and align them with the chosen approach.