Skip to content

12.1 Notification Service - Scaffold and Schema

Sprint: Sprint 12 - Notifications and Ticketing
Feature ID: 12.1
Subtasks: 12.1.1, 12.1.2

Objective

Deliver "Notification Service - Scaffold and Schema" within Sprint 12 - Notifications and Ticketing.

Dependencies

Aggregated from the subtasks below (prerequisite task IDs and enablers):

  • 3.4.1
  • Sprint 04
  • 12.1.1

Subtasks

12.1.1 Scaffold notification-service from template

  • ID: 12.1.1
  • Title: Create notification-service from the service template
  • Description: Instantiate microservices/notification-service (port 9009, base package com.telco.notification) from the template; depend on starter-api, starter-security, starter-observability, starter-inbox, starter-outbox; use MongoDB as the primary store for documents/history (ADR-006 approved exception) plus a co-located PostgreSQL database hosting only the platform outbox/inbox tables (no business tables). Architecture mode: Simple Service Layer (ADR-004) - Controller -> Service -> Repository over template CRUD plus channel adapters; no mediator/CQRS. Idempotent event consumption uses InboxService.firstSeen(...) directly in the Kafka consumers (not the mediator InboxBehavior); the single emitted event uses the Postgres outbox. Declare the architecture mode and Infrastructure Profile (MongoDB + Postgres outbox/inbox, ADR-006) in CLAUDE.md/README.
  • Business Purpose: Standardized notification-domain service skeleton.
  • Inputs: ADR-017.
  • Outputs: notification-service skeleton building and registering.
  • Acceptance Criteria:
  • Service starts, registers, exposes Swagger UI.
  • Dependencies: 3.4.1, Sprint 04
  • Complexity: S

12.1.2 Notification store: Mongo collections + Postgres outbox/inbox

  • ID: 12.1.2
  • Title: Define MongoDB collections and the PostgreSQL outbox/inbox migration
  • Description: In MongoDB, define collections notification_templates (code, channel, locale, subject, body_template), notifications (user_id, template_code, channel, payload_json, status, sent_at), and communication_preferences (user_id, channel, opted_in), with indexes (templates unique by code+channel+locale; preferences by user+channel). In the co-located PostgreSQL database, the Flyway baseline applies only the platform outbox (V900) and inbox (V901) tables - no business tables. The single emitted event notification.dispatched.v1 is written to the Postgres outbox.
  • Business Purpose: Persist templates, sent notifications, and opt-in/out preferences (FR-29, FR-30).
  • Inputs: analysis Section 10.8, FR-29, FR-30, ADR-006.
  • Outputs: MongoDB collection definitions/indexes + Postgres outbox/inbox Flyway baseline.
  • Acceptance Criteria:
  • Mongo collections exist with the stated indexes; the Postgres outbox/inbox tables exist; preferences capture per-channel opt-in/out.
  • Dependencies: 12.1.1
  • Complexity: M

Acceptance Criteria

Each subtask above carries its own objective, testable acceptance criteria. This feature is complete when every subtask's acceptance criteria are met.

Deliverables

  • notification-service skeleton building and registering.
  • MongoDB collections/indexes + Postgres outbox/inbox Flyway baseline.

Definition of Done

  • All subtasks (12.1.1, 12.1.2) completed and their acceptance criteria verified.
  • All listed dependencies satisfied.
  • Build and tests green per the global conventions in ../README.md (Section 3).