virtocommerce/vc-platform

1. What this repo is

This is the Virto Commerce Platform runtime: an ASP.NET Core/.NET 10 backend plus an AngularJS-based admin SPA. It is designed as a modular commerce platform, not a single business app. Most business capabilities are delivered as loadable modules rather than hard-coded features.

2. Top-level runtime shape

The main executable is src/VirtoCommerce.Platform.Web. It hosts HTTP APIs, authentication, Swagger, health checks, SignalR push notifications, static SPA assets, and startup/configuration wiring. The rest of the solution is split into reusable libraries that the host composes.

3. API and host boundary

Controllers under Controllers/Api expose the platform surface for modules, security, settings, localization, jobs, diagnostics, licensing, change log, and push notifications. Middleware in the web project handles API error wrapping, cache headers, security headers, and authentication/authorization behavior.

4. Core domain and contracts

VirtoCommerce.Platform.Core defines the platform’s shared abstractions and domain primitives: entities, repositories, unit of work, commands, events, settings, dynamic properties, localization, export/import, push notifications, modularity, and security contracts. This layer is intentionally persistence- and transport-agnostic.

5. Persistence and business services

VirtoCommerce.Platform.Data contains the concrete EF Core implementations for the shared platform features. It provides repository/unit-of-work infrastructure, CRUD/search services, settings storage, dynamic properties, localization, change log, countries, file/zip helpers, and transaction-aware file operations.

6. Database provider split

The repo has separate provider packages for SQL Server, PostgreSQL, and MySQL. Each contains provider-specific EF Core configuration, migrations, health checks, and certificate loading. Architecturally, this means the platform core data model is shared, while storage behavior and schema evolution are provider-specific.

7. Security subsystem

VirtoCommerce.Platform.Security and the web project together implement identity and authorization. The stack includes ASP.NET Core Identity, OpenIddict, custom user/role stores and managers, API key and basic auth handlers, permission authorization, external sign-in, server certificate management, and background jobs for token pruning and account lockout.

8. Modularity and module lifecycle

VirtoCommerce.Platform.Modules is the module runtime. It handles module discovery, manifests, cataloging, installation, versioning, optional dependencies, assembly loading, and app manifest management. This is the central extensibility boundary: modules can contribute APIs, UI, settings, data, and startup behavior.

9. Caching and scale-out coordination

VirtoCommerce.Platform.Caching and VirtoCommerce.Platform.DistributedLock provide cache regions, memory cache abstractions, Redis-backed cache invalidation, and distributed locks. This matters for multi-instance deployments where module state, settings, and notifications must stay consistent across nodes.

10. Background processing

VirtoCommerce.Platform.Hangfire integrates Hangfire for recurring and background jobs. The web host uses it for scheduled jobs and operational tasks, with explicit user-context middleware and authorization hooks for the admin experience.

11. Push notifications and real-time UI

Push notifications are modeled in Core and implemented in Web with SignalR hubs, in-memory storage, and a scalable notification manager. This is used by admin workflows and long-running operations such as module installation, export/import, and job progress.

12. Admin UI structure

The admin front end lives in wwwroot/js/app and is organized by feature areas such as security, settings, modularity, dynamic properties, change log, diagnostics, and user profile. The UI uses a blade/navigation pattern, feature-specific resources/services/widgets, and localized JSON bundles under wwwroot/Localizations.

13. Data flow through the platform

Typical request flow is: SPA or external client -> web controller -> application/service layer -> repository/EF Core -> relational database. For cross-cutting concerns, the same flow may also trigger events, cache invalidation, push notifications, or background jobs.

14. Operational/deployment boundaries

The repo includes Docker Compose files, Azure deployment templates, and GitHub workflows, indicating it is meant to run in containerized and cloud deployments. The docs also reference Redis and a broader local stack, reinforcing that the platform is built for distributed, modular commerce environments.

15. Where to draw the main diagram boxes

A useful architecture diagram would show: the Web host at the center; Core as shared contracts; Data and provider-specific persistence underneath; Modules as a runtime/plugin subsystem; Security, Caching, Distributed Lock, and Hangfire as cross-cutting services; and the AngularJS admin SPA and external clients as consumers of the APIs.