sdarbinyan 86091a4742 feat(sellers): typed domain models for future Seller Management - no logic, no API, no auth changes
Typed models only, per mission. Nothing outside the new files reads
or writes any of this yet.

New core/sellers/models/ (mirrors core/products/models,
core/auth/models convention):
- MarketplaceRef - minimal {id,slug,name} reference from a seller
  back to its marketplace, distinct from bootstrap's TenantConfig.
- SellerStatus - 'pending'|'active'|'suspended'|'disabled', no
  transition logic.
- SellerScope - {sellerId, marketplaceId}, domain-level counterpart
  to BootstrapConfig.seller (SellerConfig from the ADR-011 pass).
- SellerBranding (+SellerContact/SellerAddress/SellerThemeOverrides)
  - logo/banner/description/contacts/address/theme overrides, every
    field optional. Marketplace branding/theme remain default;
    nothing consumes this yet.
- SellerPermissionRole/SellerPermissions - marketplaceOwner/seller/
  sellerStaff/platformAdmin. Separate vocabulary from the existing
  AdminRole (core/auth/models/permission.model.ts) - not merged, not
  wired into any guard, zero auth behavior change.
- Seller - the eventual entity, composed from the above.

Changed (optional-only, verified backward compatible):
- Item (models/item.model.ts) gained sellerId?: string
- AdminProduct (features/admin/products/models/) gained
  sellerId?: string
- AdminOrder (features/admin/orders/models/) gained sellerId?: string

Absent means marketplace-owned in every case, exactly like every
existing product/order today. No consumer of any of these three
models needed updating. AdminOrderItem (per-line-item ownership) and
the existing PermissionsConfig/AdminRole system were deliberately not
touched - out of scope for this pass.

Added docs/architecture/foundation/Seller-Management-Domain-Models.md
documenting every new type, every changed field, and the explicit
non-goals list. Linked from the foundation README alongside ADR-011
and the diagrams doc.

tsc --noEmit clean, arch:check (boundaries + cycles) clean.
2026-07-26 21:55:11 +04:00
2026-07-19 15:28:35 +04:00
2026-01-18 18:57:06 +04:00
2026-06-01 00:47:26 +04:00
2026-01-18 18:57:06 +04:00
2026-07-19 15:28:35 +04:00
2026-03-24 02:25:50 +04:00
2026-07-19 15:28:35 +04:00
2026-07-09 01:40:22 +04:00
2026-05-28 12:56:41 +00:00
2026-06-21 23:42:39 +04:00

Marketplace Frontend

Angular 21 multi-tenant marketplace platform frontend. Standalone components, signals, no NgRx. One codebase serves unlimited tenants ("marketplaces") via a per-tenant bootstrap.json fetched at runtime — no tenant-specific code paths.

Three surfaces on this one codebase:

  • Storefront (/) — the public shopping site: catalog, product pages, cart, static/CMS pages.
  • Builder / Project Editor (/edit/**) — in-app editor that edits the tenant's BootstrapConfig (theme, nav, homepage sections, widgets, footer, languages, static pages).
  • Backoffice / Admin (/:lang/backoffice/**) — products, categories, orders, transactions, users, moderation, media, monitoring, analytics.

Architecture

Component (container) → Facade → Domain Service → Repository/Provider (DI token, swappable mock↔API) → Mock | API

Enforced by npm run arch:check (import boundaries + circular deps), not just convention. Full detail: docs/ARCHITECTURE.md, governance ADRs at docs/architecture/foundation/**.

Frontend status

Release Candidate — feature-complete. See docs/PROJECT_STATUS.md for the honest current-state breakdown (completion %, known limitations, readiness for demo/production/backend).

Backend

Not implemented yet — fully specified. Every domain currently runs against an in-memory/mock gateway except Categories (the one domain wired to a real HTTP API). The complete contract a backend engineer needs — every endpoint, DTO, auth flow, error model, upload contract, and a step-by-step implementation checklist — lives in one canonical document:

docs/BACKEND.md

How to switch Mock ↔ API

Toggle useMockData in src/environments/environment.ts (or environment.production.ts). RuntimeProviderStrategyService (src/app/core/providers/runtime-provider-strategy.service.ts) reads this flag per-domain to decide whether a facade gets the mock or real gateway. On localhost with useMockData: false, some domains (bootstrap, categories) still fall back to mock automatically so local dev never silently hits a real backend by accident — see that service for the exact per-domain logic.

Development

npm install       # install dependencies
npm start         # local dev server
npm run build     # production build -> dist/dexarmarket/
npm run arch:check   # import-boundary + circular-dependency check

Folder structure

src/
├── app/
│   ├── components/       # Shared storefront components (header, footer, product-card, etc.)
│   ├── core/              # Auth, admin-auth, config/tenant resolution, DI providers, interceptors
│   ├── dynamic-renderer/  # Bootstrap JSON -> section/widget rendering pipeline (live homepage engine)
│   ├── facades/           # Runtime, website, builder, and backoffice facades
│   ├── features/          # Domain features: admin/*, project-editor, content-management, website/*
│   ├── guards/            # Route guards (language, admin-auth, dirty-state, etc.)
│   ├── i18n/              # Translation service, pipe, and locale packs (en/ru/hy)
│   ├── pages/             # Top-level routed pages: home, cart, static-page
│   ├── services/          # API, cart, auth, SEO, Telegram, and language services
│   ├── shared/             # Shared UI primitives (button, dialog, confirm-dialog, table, etc.)
│   └── widgets/            # Dynamic-renderer widget components
├── assets/mock/            # Local mock configuration and catalog data
├── environments/           # Development and production environment settings (incl. useMockData)
└── styles/                 # Shared global styles and themes

Documentation map

Full index: docs/PROJECT_INDEX.md. Key entry points:

Doc What it covers
docs/PROJECT_STATUS.md Current completion status, honest limitations, demo/production readiness
docs/BACKEND.md The one canonical backend spec — endpoints, DTOs, auth, security, errors, uploads, checklist
docs/NEXT_PHASE.md Roadmap: backend integration → testing → performance → monitoring → v2
docs/TODO.md Release blockers only
docs/KNOWN-ISSUES.md Real, reproducible, currently-open frontend bugs
docs/PRODUCT_BACKLOG.md Items needing a client/business decision
DESIGN.md Visual design system
PRODUCT.md Product positioning

Notes

  • Authentication and payment integrations are on their existing contracts — see docs/BACKEND.md for the auth/security contract a real backend must satisfy.
  • Client-facing content should avoid placeholder names, mock labels, and temporary routes.
Description
No description provided
Readme 16 MiB
Languages
TypeScript 71.4%
HTML 15.3%
SCSS 11.9%
Shell 1.3%
JavaScript 0.1%