sdarbinyan/marketplaces
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

changes
Some checks failed
Architecture Governance / architecture (push) Has been cancelled
Details

Browse Source
This commit is contained in:
sdarbinyan
2026-07-19 15:28:35 +04:00
parent 71d5f4d320
commit d853ecb1da
23 changed files with 2189 additions and 1107 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/architecture/foundation/adr/ADR-004-configuration-bootstrap-and-provider-abstraction.md
View File

@@ -1,36 +1,11 @@
# ADR-004: Configuration Bootstrap and Provider Abstraction
Status: Accepted
Status: Superseded
Date: 2026-07-03
Superseded by: `docs/backend/BACKEND-INTEGRATION.md` §4 (Bootstrap) and §14 (Backend replacement pattern)
## Context
## Original decision (preserved for history)
Configuration must initially come from mock JSON and later from backend API without changing consumers.
Configuration must initially come from mock JSON and later from backend API without changing consumers. `ConfigService` is the only configuration entrypoint; consumers depend on typed selectors only; provider implementation is swappable (`MockBootstrapProvider` / `ApiBootstrapProvider`); the frontend calls `GET /bootstrap` when the API provider is enabled and never passes a tenant id.
## Decision
Introduce configuration provider abstraction behind ConfigService.
- ConfigService is the only configuration entrypoint.
- Consumers depend on typed ConfigService selectors only.
- Provider implementation is swappable:
- MockBootstrapProvider
- ApiBootstrapProvider
- Frontend calls GET /bootstrap when API provider is enabled.
- Frontend does not pass tenant id.
## Consequences
Positive:
- Source-agnostic configuration usage.
- Mock-to-backend transition with minimal change surface.
Negative:
- Requires strict prohibition of direct JSON imports in components/services.
## Compliance Requirements
- No code outside ConfigService may load bootstrap JSON.
- No page/widget/component may access configuration files directly.
This decision remains in effect. The full, verified contract — endpoint, caching, field-by-field DTO reference, and the generalized mock↔API provider-swap pattern this ADR introduced (now used by every admin domain, not just bootstrap) — lives in `docs/backend/BACKEND-INTEGRATION.md`. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.

34
docs/architecture/foundation/adr/ADR-010-backward-compatibility-for-auth-payment-authorization.md
View File

@@ -1,35 +1,11 @@
# ADR-010: Backward Compatibility for Authentication, Payment, and Authorization
Status: Accepted
Status: Superseded
Date: 2026-07-03
Superseded by: `docs/backend/BACKEND-INTEGRATION.md` §2 (Authentication), §2.8 (Payments), §2.5 (admin authorization gap)
## Context
## Original decision (preserved for history)
Authentication and payment flows are proven and contract-sensitive. Platform refactoring must not break existing integrations.
Authentication and payment flows are proven and contract-sensitive. Platform refactoring must not break existing integrations. Freeze behavior and contracts for authentication flow, payment API interactions, and authorization logic. Allow only encapsulation and integration-layer isolation, not contract redesign.
## Decision
Freeze behavior and contracts for:
- Authentication flow.
- Payment API interactions.
- Authorization logic.
Allow only encapsulation and integration-layer isolation, not contract redesign.
## Consequences
Positive:
- Prevents regressions in critical commerce and access flows.
- Enables architecture modernization around stable core behavior.
Negative:
- Some suboptimal legacy internals may remain until controlled replacement strategy is approved.
## Compliance Requirements
- Existing auth/payment request/response contracts remain unchanged.
- Behavior-equivalent wrappers/adapters are allowed.
- Any change requires explicit ADR and compatibility test evidence.
This decision remains in effect. The full, verified contract — the Telegram QR/session flow, cookie policy, the frozen payment endpoint shapes, and the still-unresolved admin-authorization gap this ADR's constraint interacts with — lives in `docs/backend/BACKEND-INTEGRATION.md` §2 and §2.5–§2.8. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.