Data Layer low complexity backendmobile
0
Dependencies
3
Dependents
1
Entities
0
Integrations

Description

Data access layer for badge taxonomy definitions stored in Supabase. Manages the configurable badge catalog per organisation including criteria configuration, icon references, and display metadata.

Feature: Achievement Badges & Status Recognition

badge-definition-repository

Summaries

The Badge Definition Repository is the persistence foundation for the organisation-specific badge catalogue, enabling each organisation to maintain a tailored recognition taxonomy without platform-level changes. By storing criteria configuration as structured JSON, it supports flexible, extensible badge definitions that can evolve with organisational needs over time. This directly reduces the total cost of ownership for the platform: new badge types do not require database schema migrations or engineering sprints. Reliable storage and retrieval of badge definitions underpins the entire recognition feature set, making this a critical enabler of the platform's configurability value proposition.

This is a low-complexity repository with no external dependencies beyond Supabase, making it a safe early-sprint deliverable. It is a hard dependency of Badge Configuration Service and therefore gates a significant portion of badge feature work. Testing should cover standard CRUD operations, the findEnabled filter (verifying only active definitions are returned for evaluation), and JSON criteria storage round-trips. Icon asset references require alignment with the asset management strategy — clarify whether these are URLs, storage bucket keys, or identifiers before implementation.

Dual execution context (backend and mobile) means Supabase client usage must be validated in both environments.

This repository wraps the badge_definitions table in Supabase, providing typed access for all CRUD and query operations. The criteria field should be stored as JSONB for queryability and retrieved as Map in Dart. findEnabled filters on an is_enabled boolean column and is the primary method used by the evaluation pipeline — ensure this column is indexed. The update method should use an optimistic locking pattern or last-write-wins depending on requirements, since concurrent admin edits are possible.

Icon references should be treated as opaque strings at this layer. In mobile context, read access is likely scoped by organisation via RLS; backend context may have broader admin-level access for CRUD operations.

Responsibilities

  • CRUD for badge definitions per organisation
  • Query enabled badge definitions for evaluation
  • Store criteria configuration as structured JSON
  • Manage badge icon asset references

Interfaces

findByOrganisation(String organisationId) -> List<BadgeDefinition>
findById(String definitionId) -> BadgeDefinition?
insert(BadgeDefinition definition) -> BadgeDefinition
update(BadgeDefinition definition) -> BadgeDefinition
delete(String definitionId)
findEnabled(String organisationId) -> List<BadgeDefinition>

Relationships

Dependents (3)

Components that depend on this component

Related Data Entities (1)

Data entities managed by this component

API Contract

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