Welcome to the Architecture Portal for the User Management System (UMS).
UMS is a satellite product of the Evolith Architecture Reference. This relationship defines how architectural decisions are made in this repository.
Evolith (parent) UMS (satellite)
───────────────────────────── ──────────────────────────────────
Defines baseline policies ──► Inherits by reference (ADR-0050)
Provides canonical patterns ──► Adopts or adapts per UMS context
Sets naming conventions ──► Conforms + documents exceptions
A UMS ADR can do one of three things relative to Evolith:
| Mode | When to use | Example |
|---|---|---|
| Adopt | Evolith policy applies as-is | ADR-0050: Naming taxonomy adopted verbatim |
| Specialize | Evolith policy applies but UMS adds constraints | ADR-0052: Immutable audit trail with SQL Server specifics |
| Override | UMS diverges from Evolith with explicit justification | ADR-0059: Single API tier decision (co-location over split tiers) |
When you encounter a decision that seems to conflict with Evolith, check the relevant UMS ADR first. The override may be intentional and justified. If no ADR exists, the Evolith baseline applies. Never assume silence means permission to deviate.
Evolith permits splitting query and command surfaces into separate API tiers when scale or team ownership justifies it. UMS explicitly decided not to do this at current maturity:
This decision is recorded in ADR-0059 with explicit triggers for when the decision should be revisited.
This is the intended pattern: inherit the baseline, override with evidence, document the trigger to revert.
This section focuses on the structural design and database models of the system.
Detailed engineering blueprints focusing on:
Cross-reference of all Functional Stories (FS-01..16) to ADRs and Technical Enablers.
Engineering blueprints specifying how ADRs are implemented in the UMS context:
Reference implementations for core architectural patterns:
| Back to Master Index | Back to Root README |