Service Factory

What a service factory does

A service factory sits between a caller and the concrete service it needs. Rather than exposing selection rules to consumers, it decides which implementation to return based on runtime conditions, then hands back an object that can still participate in normal dependency injection for its own collaborators. That keeps creation policy separate from usage.

The key value of the pattern is indirection with control. Consumers depend on a stable service contract, while the factory absorbs variation such as environment, tenant, feature flag, request context, or deployment mode. That makes the application easier to change without forcing callers to know which implementation is active.

How a service factory differs from direct instantiation

Direct instantiation couples a caller to one concrete type and to the details of how that type is built. A service factory removes that coupling by centralising the decision logic in one place. The caller asks for a service; the factory resolves the right one, often by consulting configuration or runtime state.

This is not the same as a simple helper method that always returns one object. A service factory is useful when the returned implementation genuinely varies, or when you need a consistent way to choose between multiple registered services without spreading conditionals across the codebase.

Because the factory hides selection logic, it also helps preserve cleaner dependency graphs. The service it returns can still use injected repositories, clients, loggers, or other collaborators, but the consumer only sees the service abstraction and not the wiring underneath.

Where service factories are commonly used

Service factories appear in systems that need runtime routing or behavioural switching. Common examples include multi-tenant applications, region-aware services, request-scoped behaviours, and systems that select implementations based on policy or capability. They are also useful when a platform must support multiple back ends behind one contract.

They are especially valuable when the choice of implementation is a business decision rather than a technical detail the caller should own. For example, an application may route to one service for premium customers and another for standard customers, or choose a local versus remote provider depending on operating mode.

In well-structured code, the factory becomes the single point that knows the selection criteria. That reduces scattered branching, keeps construction concerns out of domain logic, and makes the active implementation easier to test in isolation.

Design trade-offs and maintainability considerations

Service factories improve separation of concerns, but they also introduce an extra layer of indirection. If the selection rules become too complex, the factory can turn into a hidden decision engine that is harder to reason about than the services it creates. At that point, naming, documentation, and clear boundaries matter.

Another trade-off is discoverability. When consumers no longer instantiate their own dependencies, the active implementation may be less obvious from the call site. That is usually acceptable when the variability is intentional, but it means the factory contract should be explicit about what inputs influence selection and what guarantees the returned service provides.

The pattern works best when the variability is real and stable enough to justify abstraction. If there is only one implementation, or if selection is trivial and never expected to change, a factory can add ceremony without much benefit.

Related resources from NHI Mgmt Group

• How should teams design a service factory when multiple implementations must be selected at runtime without changing existing code?
• What is the difference between a service factory and a service factory builder in dependency injection?
• What makes a super NHI different from an ordinary service account?
• What problem does ownership attribution solve for service accounts and API keys?