Transactional Data Architecture¶

Executive Summary¶

Transactional Data Architecture defines PostgreSQL as the core operational database for Algosure. It stores domain-owned source facts, workflow state, tenant context, organization context, event/outbox data, audit references, and transactional records.

Why This Exists¶

The Spring Boot Modulith backend needs a reliable operational store that preserves DDD ownership, module boundaries, tenant isolation, and transactional consistency without forcing premature distributed data architecture.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

PostgreSQL as the primary operational store supports clear ownership, strong consistency where required, transaction safety, auditability, and future service extraction paths.

Transactional Store View¶

flowchart TB
    Backend[Spring Boot Modulith Backend]
    Identity[Identity Module]
    Organization[Organization Module]
    Domains[Domain Modules]
    Postgres[(PostgreSQL)]
    Outbox[(Outbox Records)]
    AuditRef[(Audit References)]

    Backend --> Identity
    Backend --> Organization
    Backend --> Domains
    Identity --> Postgres
    Organization --> Postgres
    Domains --> Postgres
    Domains --> Outbox
    Domains --> AuditRef

PostgreSQL Responsibilities¶

Responsibility	Meaning
Domain-owned transactional state	Stores operational facts and lifecycle state owned by each Domain.
Tenant and organization context	Carries TenantId and OrganizationId where customer-scoped data exists.
Workflow state	Stores process state owned by relevant Domains and workflow application services.
Event/outbox data	Stores domain events and outbox records for reliable event publication where required.
Audit references	Stores structured references to audit evidence where appropriate.
Configuration and policy data	Stores Administration-owned platform configuration and policy state where operationally required.

Domain-Owned Persistence Rules¶

Rule	Requirement
Domain-owned schemas or tables	Persistence structures must map to owning Domains and avoid shared ownership.
No direct database ownership violations	A module must not read or write another module's owned records directly.
Cross-domain references use identifiers	Modules may store stable foreign identifiers but must not duplicate mutable source facts.
Tenant filtering is mandatory	Repository and query boundaries must enforce tenant and organization context for customer data.
Migrations follow ownership	Database changes are owned by the module that owns the affected data.
Operational facts stay operational	Reporting, search, and AI memory projections do not replace PostgreSQL source facts.

Multi-Tenant Data Model¶

Context	Requirement
TenantId	Required for tenant-scoped customer data.
OrganizationId	Required where data belongs to or is interpreted for a customer organization.
UserId / ActorId	Required where actor traceability, ownership, assignment, or audit matters.
CorrelationId	Required where workflow, event, integration, or AIOS tracing matters.
Classification	Required where sensitivity, retention, access, or document handling depends on data type.

Non-Implementation Boundary¶

This document does not define final SQL, schema names, table names, entity mappings, indexes, migration tooling, or PostgreSQL row-level security policy syntax.