Service Layer medium complexity backendmobile
1
Dependencies
0
Dependents
2
Entities
0
Integrations

Description

Manages the per-organisation configurable badge taxonomy, allowing organisations to define, enable, or disable badge types without code changes. Loads badge definitions from Supabase and provides them to the evaluation and UI layers.

Feature: Achievement Badges & Status Recognition

badge-configuration-service

Summaries

The Badge Configuration Service gives each organisation full control over its recognition program without requiring software releases or engineering involvement. Organisations can define, enable, or disable badge types independently, dramatically reducing the cost and time of tailoring the platform to local needs. This flexibility is a direct competitive differentiator: organisations that feel ownership over their recognition taxonomy are more likely to adopt and retain the platform long-term. Reducing dependency on code changes also lowers operational risk and support burden, translating to measurable cost savings across the customer base.

This service has medium complexity and sits on the critical path for badge feature delivery, as both the evaluation engine and the UI depend on it to load definitions. It requires a working Supabase schema for badge_definition and must be completed before downstream badge evaluation or coordinator admin screens can be integrated and tested. Caching logic adds some implementation risk — cache invalidation on updates must be validated under concurrent load. Testing should include admin CRUD flows, cache reload verification, and criteria validation edge cases.

Delivery is well-scoped but cannot be parallelised with badge evaluation work.

This service acts as the authoritative source of badge taxonomy data, abstracting Supabase reads through a caching layer keyed by organisationId. It wraps badge-definition-repository for persistence and exposes a clean service interface to both the badge evaluation engine and UI layers. The reloadCache method must be triggered after any CUD operation to maintain consistency. validateCriteriaConfig should perform schema-level checks against the expected criteria structure before persisting.

Since it executes in both backend and mobile contexts, implementations must be careful about cache lifecycle differences between long-running server processes and short-lived mobile app sessions.

Responsibilities

  • Load and cache badge definitions per organisation
  • Support CRUD for badge definitions by org admins
  • Validate badge criteria configuration on save
  • Provide badge definitions to evaluation and UI

Interfaces

getBadgeDefinitions(String organisationId) -> List<BadgeDefinition>
createBadgeDefinition(BadgeDefinition definition) -> BadgeDefinition
updateBadgeDefinition(BadgeDefinition definition) -> BadgeDefinition
deleteBadgeDefinition(String definitionId)
validateCriteriaConfig(Map<String, dynamic> criteria) -> ValidationResult
reloadCache(String organisationId)

Relationships

Dependencies (1)

Components this component depends on

Related Data Entities (2)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/badge-definitions 5 endpoints
GET /api/v1/badge-definitions
GET /api/v1/badge-definitions/:id
POST /api/v1/badge-definitions
PUT /api/v1/badge-definitions/:id
DELETE /api/v1/badge-definitions/:id