Adds accounting-service PATCH/archive, fiscal helpers, COA templates and setup status, plus SuperApp Accounting UI (DS, scoreboard, masters, vouchers, ledger, ops modules) with session refresh and HTTPS public API URLs. Co-authored-by: Cursor <cursoragent@cursor.com>
46 lines
1.3 KiB
Markdown
46 lines
1.3 KiB
Markdown
# ADR-001: Database-per-Service
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Status | Accepted |
|
|
| Date | 2025-01-01 |
|
|
| Deciders | Platform Architecture |
|
|
| Supersedes | — |
|
|
| Superseded by | — |
|
|
|
|
## Context
|
|
|
|
TorbatYar is a multi-tenant SuperApp that will grow to many business modules. Shared databases create tight coupling, migration contention, and cross-team schema conflicts.
|
|
|
|
## Decision
|
|
|
|
Every service owns exactly one database. Cross-service data access is forbidden. Services communicate only via REST API, Webhook, Async Event, and Outbox/Inbox.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- Independent schema evolution per service
|
|
- Clear ownership boundaries
|
|
- Microservice-ready from day one
|
|
|
|
### Negative
|
|
|
|
- No cross-DB joins; eventual consistency required
|
|
- Duplicate reference data must be synchronized via events/APIs
|
|
|
|
### Neutral
|
|
|
|
- Core Platform database (`core_platform_db`) remains the registry for tenants, plans, entitlements, and service discovery
|
|
|
|
## Alternatives Considered
|
|
|
|
1. Shared monolithic database with schema prefixes
|
|
2. Schema-per-tenant in one database
|
|
|
|
## Related Documents
|
|
|
|
- [Database Architecture](../database-architecture.md)
|
|
- [Service Architecture](../service-architecture.md)
|
|
- [Services Contracts](../../reference/services-contracts.md)
|