Skip to main content

Notification Value Conversions and JSON Fields

Summary​

The model declares no value conversion, no owned type and no JSON column. Every enumerated concept is a plain string backed by a constants class rather than a C# enum, so no conversion is needed.

Audience​

Engineers, architects, QA and support.

Reference Content​

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

String-constant convention​

Six concepts that would conventionally be enums are instead static class constant holders, and the entity properties that carry them are declared as string. The source comment on the channel holder states the rationale: strings are used for forward compatibility.

ConceptValuesColumn length
Channels4 — in-app, email, SMS, WhatsApp40
Recipient types4 — user, employee, role, address40
Message statuses5 — pending, sent, failed, read, skipped40
Delivery statuses3 — success, failed, skipped40
Processing outcomes7 — processed, duplicate, stale, no template, no recipient, suppressed, failed40
Audit stages13 — received through read40

Consequences​

No conversion layer. Values are written and read as-is, so what is in the column is exactly what the application assigned.

No database-level validation. Because these are plain strings with no check constraint, any value within the length limit can be stored. The defined sets are a convention enforced only by application code assigning from the constants.

Case sensitivity matters. Only the channel concept has a normalisation helper, which maps a case-insensitive input to canonical casing and is applied on the template create path and during dispatch. The other five concepts have no normaliser, so a value written with different casing by any future path would not match an equality filter.

Comparisons are string comparisons. Every status, stage and outcome filter in every query is a string equality test.

Verified absence​

  • No HasConversion call anywhere in the model.
  • No OwnsOne or OwnsMany — the model has no owned or complex types, and no value object is persisted.
  • No ToJson call and no jsonb or json column type. The only explicitly typed columns are two text bodies.
  • No enum-to-string or enum-to-int converter, because no entity property is a C# enum.
  • No encrypted, hashed or otherwise transformed column.
  • No custom ValueComparer and no custom type mapping.

JSON handling outside the database​

The test-dispatch and test-publish paths accept a free-form JSON payload, and the event envelope carries a raw payload string. That payload is parsed and used to build notification content, but it is never persisted — no column stores the source event payload. Only the rendered subject and body reach the database.

Classification​

Foundation — the plain-string convention is deliberate and consistent; no conversion infrastructure exists.

Requires confirmation​

Whether check constraints or normalisation for the five un-normalised string sets are intended requires confirmation.

See Also​

Keywords​

  • Notification database
  • Value Conversions
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
  • microservices/src/notification-service/Domain/NotificationEntities.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs

Revision Information​

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