TorbatYar/docs/architecture/adr/ADR-001.md
Mortezakoohjani 12c8615615 Ship enterprise Accounting FE/API with CRUD parity and production wiring.
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>
2026-07-24 15:26:43 +03:30

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)