Dream Consistency Architecture
Locked and evolving technical decisions shared across Dream Consistency products,
Realms, services, shared libraries, and infrastructure.
This area records architecture decisions that define long-term Dream Consistency
standards and technical direction.
Product documentation explains how a system works. Architecture Decisions explain
what has been intentionally standardized, which boundaries are considered authoritative,
and which design directions new implementations must follow.
Rule:
Shared security, service communication, data ownership, Realm topology,
cross-product contracts, and other long-term platform decisions should be documented
here before they become implementation conventions.
| Status |
Meaning |
| LOCKED |
Current architecture standard. New implementations must follow it unless
a new explicit architecture decision replaces it.
|
| ACTIVE / EVOLVING |
The main direction is accepted, but some implementation or domain details
are still being finalized.
|
| SUPERSEDED |
Historical decision retained for context but replaced by a newer architecture decision.
|
Service-to-Service Communication
Internal API-to-API communication standard covering Client NuGet packages,
ServiceAuth request signing, caller identity, authorization boundaries,
transport security, replay protection, and service deployment identity.
Open Decision →
Core Accounts & AccessControl
Product-neutral account lifecycle and authentication boundaries.
AccessControl remains the authentication authority, Accounts becomes the
clean Realm account lifecycle service, and UserAccounts remains legacy compatibility.
Open Decision →
Realm Federation & Billing
Master direction for multi-Realm architecture, CentralManagement federation,
hosted and self-hosted product topology, Billing ownership, and reusable
Dream Consistency financial services.
Open Decision →
Prefer explicit service boundaries over shared database access.
Shared Dream Consistency services remain product-neutral.
A Realm is an independent deployment and data boundary.
Cross-database workflows are retry-safe and idempotent,
not modeled as fake distributed transactions.
API servers own their server-side contracts and domain logic.
Client NuGet packages are consumer SDKs, not server dependencies.
Central standards are shared.
Product-specific business logic stays inside the product.
| Date |
Change |
Author |
| 2026-09-30 |
Created Architecture Decisions hub and added the initial shared Dream Consistency
architecture decisions.
|
Branko |