Notification Aggregates¶

Why This Exists¶

This document defines aggregate boundaries for the Notification Domain.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

Aggregate boundaries keep delivery, preferences, scheduling, templates, and history reliable even when many domains request notifications.

Aggregate Map¶

flowchart TD
    Request[Notification Request Aggregate]
    Notification[Notification Aggregate]
    Preference[Notification Preference Aggregate]
    Template[Notification Template Aggregate]
    Schedule[Notification Schedule Aggregate]
    Delivery[Delivery Aggregate]
    Escalation[Escalation Aggregate]
    History[Communication History Aggregate]

    Request --> Notification
    Notification --> Preference
    Notification --> Template
    Notification --> Schedule
    Schedule --> Delivery
    Delivery --> Escalation
    Delivery --> History

Notification Request Aggregate¶

The Notification Request aggregate records the request from another domain or internal workflow. It owns the source reference, notification type, requested recipients, requested priority, and reason.

Invariants¶

A request must have a source domain or source system.
A request must reference business facts by ID, not duplicate them as owned state.
A request must define at least one recipient target or recipient resolution rule.

Notification Aggregate¶

The Notification aggregate owns the message instance, recipients, rendered template reference, priority, schedule reference, read status, and lifecycle.

Invariants¶

A notification must have a type, priority, recipient, and channel plan.
A notification cannot be marked delivered without at least one successful delivery attempt.
Read status is recipient-specific.

Notification Preference Aggregate¶

The Notification Preference aggregate owns user or organization preferences for channels, quiet hours, frequency, and opt-in or opt-out where allowed.

Invariants¶

Critical procurement notifications may override non-essential suppression only under documented policy.
Preferences must be scoped to user, role, organization, notification type, or channel.
Preference changes must be auditable.

Notification Template Aggregate¶

The Notification Template aggregate owns approved message templates by type, channel, language, and version.

Invariants¶

A template must be approved before production use.
Template variables must be explicit and validated.
Historical notifications must retain the template version used.

Notification Schedule Aggregate¶

The Notification Schedule aggregate owns timing rules for immediate, delayed, repeated, or deadline-relative delivery.

Invariants¶

A scheduled notification must have a due time or trigger rule.
Repeat schedules must have a stop condition.
Schedules must respect preference policies unless an escalation policy applies.

Delivery Aggregate¶

The Delivery aggregate owns channel delivery attempts, provider responses, status, retries, and failures.

Invariants¶

Each delivery attempt must be associated with a notification and channel.
Failed attempts must retain provider response metadata where available.
Retry logic must respect channel limits and escalation policy.

Escalation Aggregate¶

The Escalation aggregate owns escalation rules and escalation instances when a message is unread, undelivered, or not acted on within a defined time.

Invariants¶

Escalation must have a reason, threshold, and target.
Escalation must not mutate the source domain's business facts.

Communication History Aggregate¶

Communication History owns the audit record of sent, failed, delivered, read, acknowledged, dismissed, or escalated notifications.

Invariants¶

History records should be append-only.
History must link to source references and delivery attempts.
Sensitive message content must follow retention and privacy policy.