9e9c11dff2
Documentation only, no code. Synthesizes the 3 prior audits (Seller-Management.md, the Backoffice readiness audit, the Storefront audit) plus BACKEND.md SS11 into one migration plan covering all 17 requested modules: Authentication, Authorization, Bootstrap, Products, Categories, Orders, Payments, Transactions, Reviews, Analytics, Media, Search, CMS, Builder, Settings, Notifications, Emails, Audit Logs. Per module: current behavior, future behavior, migration strategy, backward compatibility, risk, effort, and an endpoint classification (No change / Minor change / Major change / New endpoint) grounded in facts already established in the prior audits - no new exploration, no invented specifics. Headline finding: Orders (the Unified-vs-Split-Orders decision) is the single highest-risk, most consequential item in the whole plan - payments/refunds/reporting all depend on it, and it can't be resolved by an additive field the way every other domain's seller-scoping can. Payments stays untouched (ADR-010, frozen) under the Unified path; only Split Orders would ever touch the payment flow, and only then with the same scrutiny the original frozen implementation got. Cross-cutting sections included per mission: Database changes (one nullable seller_id column touches existing tables, everything else is new tables - no NOT NULL migration ever required), Permission changes, Caching (bootstrap cache key must include resolved seller identity), Indexes, Security (seller-to-seller isolation treated with tenant-isolation rigor), Performance, API Versioning (ties to the already-open BACKEND.md SS2.10 decision), Migration order (14 numbered dependency steps), and 6 recommended implementation phases (A: Foundation through F: Operational polish). Every phase explicitly re-asserts the non-negotiable constraint: modules.sellerManagement.enabled=false must show zero behavioral difference before/after each phase ships. Linked from docs/architecture/foundation/README.md alongside the other Seller Management docs.
128 lines
5.8 KiB
Markdown
128 lines
5.8 KiB
Markdown
# Marketplace Platform Architecture Foundation
|
|
|
|
Status: Approved
|
|
Owner: Lead Software Architect
|
|
Date: 2026-07-03
|
|
|
|
## Purpose
|
|
|
|
This folder defines the mandatory engineering governance for transforming this codebase into a reusable, configuration-driven, multi-tenant Marketplace Platform (Marketplace-as-a-Service).
|
|
|
|
This repository is not treated as a single marketplace website.
|
|
It is a platform runtime that must support unlimited tenants from one Angular application.
|
|
|
|
## Platform Principles
|
|
|
|
- One codebase, unlimited tenants.
|
|
- Every tenant has three surfaces: Website, Builder, Backoffice.
|
|
- Frontend contains no tenant-specific implementation code.
|
|
- Tenant behavior is controlled by configuration loaded at bootstrap.
|
|
- Authentication, payment, authorization behavior and contracts remain unchanged.
|
|
- Prefer composition over inheritance.
|
|
- Prefer configuration over conditionals.
|
|
- No circular dependencies.
|
|
- Shared and UI layers are feature-agnostic.
|
|
|
|
## Non-Negotiable Constraints
|
|
|
|
- Authentication behavior remains exactly as current implementation.
|
|
- Payment API behavior remains exactly as current implementation.
|
|
- Authorization behavior remains exactly as current implementation.
|
|
- Existing authentication and payment API contracts cannot be changed.
|
|
- Proven modules are reused, wrapped, and isolated, not redesigned.
|
|
|
|
## Document Set
|
|
|
|
### Architecture Decision Records
|
|
|
|
- [ADR-001](adr/ADR-001-platform-model.md)
|
|
- [ADR-002](adr/ADR-002-layered-feature-architecture.md)
|
|
- [ADR-003](adr/ADR-003-import-boundaries-and-dependency-direction.md)
|
|
- [ADR-004](adr/ADR-004-configuration-bootstrap-and-provider-abstraction.md)
|
|
- [ADR-005](adr/ADR-005-dynamic-page-section-widget-rendering.md)
|
|
- [ADR-006](adr/ADR-006-ui-component-purity-and-container-facade-pattern.md)
|
|
- [ADR-007](adr/ADR-007-state-management-and-facade-boundaries.md)
|
|
- [ADR-008](adr/ADR-008-theme-engine-and-design-token-runtime.md)
|
|
- [ADR-009](adr/ADR-009-feature-flags-and-capability-guards.md)
|
|
- [ADR-010](adr/ADR-010-backward-compatibility-for-auth-payment-authorization.md)
|
|
- [ADR-011](adr/ADR-011-optional-seller-management-module.md)
|
|
|
|
### Seller Management (optional, in preparation — not built)
|
|
|
|
- [Seller-Management.md](Seller-Management.md) — capability overview, start here
|
|
- [ADR-011](adr/ADR-011-optional-seller-management-module.md) — decision record
|
|
- [Seller-Management-Diagrams.md](Seller-Management-Diagrams.md) — hierarchy, bootstrap gate, type diagram
|
|
- [Seller-Management-Domain-Models.md](Seller-Management-Domain-Models.md) — typed models, optional sellerId fields
|
|
- [Seller-Management-UX-Review.md](Seller-Management-UX-Review.md) — UX/accessibility review of the Phase 1 UI
|
|
- [Seller-Management-Backoffice-Readiness-Audit.md](Seller-Management-Backoffice-Readiness-Audit.md) — per-module scoping/permissions readiness audit
|
|
- [Seller-Management-Storefront-Audit.md](Seller-Management-Storefront-Audit.md) — `market.com`/`seller.market.com` storefront readiness audit
|
|
- [Seller-Management-Backend-Migration-Plan.md](Seller-Management-Backend-Migration-Plan.md) — full backend migration plan, module-by-module, phased
|
|
|
|
### Engineering Rule Documents
|
|
|
|
- [Folder Blueprint](Folder-Blueprint.md)
|
|
- [Import Boundary Matrix](Import-Boundary-Matrix.md)
|
|
- [Dependency Rules](Dependency-Rules.md)
|
|
- [Naming Conventions](Naming-Conventions.md)
|
|
- [Coding Standards](Coding-Standards.md)
|
|
- [Component Standards](Component-Standards.md)
|
|
- [Service Standards](Service-Standards.md)
|
|
- [Configuration Standards](Configuration-Standards.md)
|
|
- [State Management Standards](State-Management-Standards.md)
|
|
|
|
## Compliance
|
|
|
|
All new work must comply with this foundation.
|
|
If an implementation conflicts with these rules, implementation must be adjusted.
|
|
If a rule must change, an ADR update is required first.
|
|
|
|
## Sprint 11.5 Standardization Audit (2026-07-09)
|
|
|
|
Platform-wide standardization was executed before Admin Platform work.
|
|
|
|
### Completed Standardization
|
|
|
|
- Verified and enforced container/facade/domain/infrastructure boundaries across active website features.
|
|
- Removed remaining legacy variant naming in application-layer templates/styles.
|
|
- Removed duplicate legacy search-history implementation in catalog feature module.
|
|
- Standardized design-token surface with explicit spacing, radius, shadow, and transition tokens.
|
|
- Added widget metadata support for title/subtitle/visibility/layout/animation/style/permissions in shared contracts and dynamic rendering path.
|
|
- Converted remaining identified hardcoded UI strings in audited runtime pages/components to translation keys.
|
|
|
|
### Bootstrap/Configuration Gaps Identified
|
|
|
|
- Widget permission model supports auth gating but role/permission enforcement is limited by current auth session shape (no role list in session model).
|
|
- Popular search defaults are currently facade-local and should be moved to bootstrap-configurable catalog search settings.
|
|
- Storage key naming conventions for local persistence are platform-scoped but still static constants; optional bootstrap override could improve tenant isolation.
|
|
|
|
### Validation Baseline
|
|
|
|
- Build and architecture checks are required for acceptance of this sprint.
|
|
- Final details and file-level changes are tracked in `Platform-Standardization-Report.md`.
|
|
|
|
## Mandatory Phase Order
|
|
|
|
Implementation must proceed only in this order:
|
|
|
|
1. Foundation structure only, app compiles.
|
|
2. Shared interfaces and types only.
|
|
3. Mocked configuration payloads only.
|
|
4. ConfigService abstraction only.
|
|
5. Theme engine.
|
|
6. Dynamic rendering engine.
|
|
7. Reusable widget library.
|
|
8. Website from configuration.
|
|
9. Builder from configuration domain.
|
|
10. Backoffice from business domain.
|
|
11. Backend documentation.
|
|
|
|
For each phase:
|
|
|
|
1. Explain what will be created.
|
|
2. Explain why.
|
|
3. List files to create.
|
|
4. Explain dependencies.
|
|
5. Implement only that phase.
|
|
6. Verify build integrity.
|
|
7. Stop and wait.
|