Skip to main content

Notification DbContexts

Summary​

Two persistence contexts map Notification data: NotificationDbContext in the extracted service, and the monolith's shared AppDbContext which maps three legacy notification tables among many others.

Audience​

Engineers, architects, QA, support and security reviewers.

Reference Content​

The verified reference material for this topic is set out in the sections below.

NotificationDbContext​

  • Purpose: owns the notification schema — templates, recipients, messages, delivery attempts, preferences, audit and the idempotency ledger.
  • Declaration: a sealed class deriving from DbContext, taking typed options through its constructor.
  • Default schema: notification, set in OnModelCreating.
  • Source: microservices/src/notification-service/Infrastructure/NotificationDbContext.cs

DbSets — seven, all exposed as expression-bodied Set<T>() properties:

PropertyEntityTable
TemplatesNotificationTemplateNotificationTemplates
RecipientsNotificationRecipientNotificationRecipients
MessagesNotificationMessageNotificationMessages
DeliveryAttemptsNotificationDeliveryAttemptNotificationDeliveryAttempts
PreferencesNotificationPreferenceNotificationPreferences
AuditLogNotificationAuditLogNotificationAuditLog
ProcessedEventsProcessedIntegrationEventProcessedIntegrationEvents

Tenant filtering: none. No HasQueryFilter is declared for any entity. The class documentation records this as intentional for a cross-tenant consumer.

SaveChanges behavior: neither SaveChanges nor SaveChangesAsync is overridden. There is no interceptor, no ChangeTracker hook and no SavingChanges event handler. Nothing is stamped automatically — every timestamp written to the database is assigned explicitly by calling code.

Audit behavior: the context performs no automatic auditing. Audit rows are appended explicitly by the dispatcher and by one API handler.

Design-time factory​

NotificationDbContextFactory implements the Entity Framework design-time factory interface and is declared in the same file. It exists so migration tooling can construct a context outside the host. It reads a connection string from an environment variable and falls back to a local development default when unset.

That fallback is a development convenience embedded in source. It is noted here as a governance observation; its value is not reproduced in this documentation.

Monolith AppDbContext​

  • Purpose: the monolith's shared context, mapping the whole legacy application including three notification tables.
  • Notification DbSets: Notifications, UserNotifications and NotificationTemplates.
  • Tenant filtering: present. All three declare a query filter combining a super-admin bypass with a current-tenant comparison; the template filter additionally admits rows with no tenant, making them global defaults.
  • Fluent configuration: limited to a few length constraints and two indexes for the notification tables.
  • Source: Data/AppDbContext.cs

Verified absence​

There is no second context inside the Notification Service, no read-model or reporting context, no keyless entity type and no database view mapped anywhere in the reviewed source.

Classification​

Transitional.

Requires confirmation​

Whether the design-time development fallback is acceptable to retain, and whether the legacy context's notification tables will be retired, require confirmation.

See Also​

Keywords​

  • Notification database
  • DbContexts
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
  • Data/AppDbContext.cs
  • microservices/src/notification-service/Program.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly