Database Specification Standard¶
Purpose¶
The Database Specification Standard defines the required content for future database specifications.
Required Specification Fields¶
| Field | Requirement |
|---|---|
| Owning module | Spring Boot Modulith module that owns the data. |
| Owning Domain | Domain that owns the source facts. |
| Data category | Source fact, workflow state, audit, outbox, read model, configuration, or projection. |
| Tenant scope | Whether TenantId and OrganizationId are required. |
| Table purpose | Business responsibility and lifecycle. |
| Columns | Column names, meanings, nullability, classification, and ownership. |
| Keys | Primary key, unique keys, and reference keys. |
| Constraints | Business, integrity, and uniqueness constraints. |
| Indexes | Query-driven indexes and ownership. |
| Audit columns | Created, updated, actor, correlation, causation, and soft-delete fields where applicable. |
| Optimistic locking | Versioning strategy for mutable records. |
| Migration owner | Module and changelog ownership. |
| Retention | Retention, archive, legal hold, and deletion expectations. |
| Tests | Migration, repository, tenant, and integrity test expectations. |
Specification Boundary¶
flowchart LR
Domain[Owning Domain]
Module[Owning Module]
Spec[Database Spec]
Migration[Liquibase ChangeSet]
Repository[Private Repository]
Table[(PostgreSQL Table)]
Domain --> Module
Module --> Spec
Spec --> Migration
Migration --> Table
Repository --> Table
Rules¶
- Database specs must use Domain language.
- Specs must state whether data is source fact, projection, audit, or operational support data.
- Specs must not define tables owned by more than one module.
- Specs must not permit cross-module repository or table access.
- Specs must identify tenant and organization columns where customer data is stored.
- Specs must include audit and migration expectations before implementation begins.