backend-services

Backend services in the Drumr Framework use constructor injection and specific decorators to consume shared dependencies. You create reusable services by applying Service decorators and BaseService usage instead of generic web framework patterns to keep logic out of actions and workflows.

You should create a shared backend service when logic needs to be reused across multiple actions, workflows, or data models. If the logic is specific to a single action and not shared, keeping it local to that action is the better approach to maintain clear service boundaries.

Singleton and request-scoped service lifecycles determine how long a service instance persists. Singleton services live for the application duration, while request-scoped services are created per individual request. The framework uses app lifecycle hooks for startup, shutdown, and error handling.

Yes, you can replace backend services for tests or environments using service replacement and strategy patterns. The framework supports dynamic provider resolution by string ID, allowing you to select runtime providers and override services as needed for different contexts.

Yes, this approach works for building notification adapters, audit context services, shared business rules, and replaceable infrastructure components. The dependency container conventions and service design patterns specifically target these types of shared backend logic requirements.

Dynamic provider resolution by string ID requires exact framework-specific service and app patterns. You must follow strict dependency container conventions and Service decorators rather than generic web framework patterns, which means the design is tightly coupled to the Drumr Framework backend architecture.