Files

sdarbinyan f4b92c7909 docs: Storefront audit for market.com/seller.market.com compatibility

Audit only, no code changed - facts gathered by reading current
source (routes, containers, header/footer, SeoService), not assumed.
Covers Homepage, Categories, Products, Search, Favorites, Cart,
Checkout, Reviews, SEO, Breadcrumbs, Header, Footer.

Core finding: tenant resolution is already entirely backend-side by
request Host (ADR-001) - the frontend just consumes whatever bootstrap
comes back for whatever hostname it's running on. A seller subdomain
is architecturally closer to already working than any part of the
Backoffice audit found; the real gaps are all about whether the
*data* rendered carries a seller-aware value, not about routing/
hosting.

Key findings:
- Canonical URLs already correct today - SeoService.siteUrl derives
  from location.origin dynamically, not hardcoded. Nothing to change.
- Header/Footer/SEO branding all read through one shared facade
  (UiRuntimeFacade.reloadFromBootstrap()) - a single future injection
  point that would cascade to all three for free, rather than three
  separate fixes.
- SeoService.setItemMeta() (per-product OG/canonical tags) is defined
  but never called anywhere in the codebase today - a pre-existing
  dead hook, unrelated to seller-scoping but blocking any future
  per-product/per-seller SEO work until wired.
- No dedicated breadcrumb component/service exists anywhere in the
  storefront - the only breadcrumb logic in the app is one local
  signal in catalog-container.component.ts.
- Checkout is not a separate route - it's an inline popup flow in
  cart.component.ts, with no multi-vendor/multi-seller cart concept
  at all. This is where Checkout Modes and Unified/Split Orders (both
  marked Future in Seller-Management.md) would actually need to land.
- Structured data (JSON-LD) and sitemap generation don't exist for
  anyone today, marketplace or seller - net-new work either way, not
  seller-specific gaps.
- One pre-existing, unrelated issue noted in passing: og:locale is
  hardcoded 'ru_RU' in SeoService - flagged, not fixed (out of scope).

Linked from docs/architecture/foundation/README.md alongside the
other Seller Management docs.

2026-07-26 22:32:41 +04:00

5.6 KiB

Raw Blame History

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

Seller Management (optional, in preparation — not built)

Seller-Management.md — capability overview, start here
ADR-011 — decision record
Seller-Management-Diagrams.md — hierarchy, bootstrap gate, type diagram
Seller-Management-Domain-Models.md — typed models, optional sellerId fields
Seller-Management-UX-Review.md — UX/accessibility review of the Phase 1 UI
Seller-Management-Backoffice-Readiness-Audit.md — per-module scoping/permissions readiness audit
Seller-Management-Storefront-Audit.md — market.com/seller.market.com storefront readiness audit

Engineering Rule Documents

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:

Foundation structure only, app compiles.
Shared interfaces and types only.
Mocked configuration payloads only.
ConfigService abstraction only.
Theme engine.
Dynamic rendering engine.
Reusable widget library.
Website from configuration.
Builder from configuration domain.
Backoffice from business domain.
Backend documentation.

For each phase:

Explain what will be created.
Explain why.
List files to create.
Explain dependencies.
Implement only that phase.
Verify build integrity.
Stop and wait.

5.6 KiB Raw Blame History