Solution Description:

This is the backend solution for the Sales sample application. It is organized into multiple projects that follow a layered architecture so each concern is isolated and easy to run locally.

The entire backend solution is approximately 7,200 lines of code (LOC) across all projects. This is a rough estimate intended to give a sense of scale.

Projects:

Sales.AI - AI/ML helpers for features such as recommendations. ~300 LOC

Sales.Api — ASP.NET Core Web API and app host. Exposes HTTP endpoints and configures services. ~900 LOC

Sales.Archives - Archive management and historical data storage. ~500 LOC

Sales.Calendar - Provides services for managing calendar, subscriptions, events, availability windows, recurrence rules, and conflict detection. ~600 LOC

Sales.Data — Entity Framework Core data access layer and migrations. ~400 LOC

Sales.Domain — Pure domain model (entities, value objects, domain rules) and business logic. ~800 LOC

Sales.Fulfillment - Order fulfillment and logistics management. ~1,200 LOC

Sales.Maintenance - Background and operational services for the Sales backend. ~420 LOC

Sales.MessageBroker - Message broker for realtime asynchronous communication. ~350 LOC

Sales.Services — Application services and orchestration. ~700 LOC

Sales.Utility — Shared helpers and utilities used across the solution. ~200 LOC

Sales.Desktop.Manager — WPF desktop client that consumes the API. ~1,000 LOC

High-level integration:

Sales.Api depends on Sales.Services, Sales.Domain, and Sales.Data to serve HTTP requests.

Sales.Data depends on Sales.Domain for entity types and contains EF Core migrations; Sales.Api is the typical startup project for design-time EF operations.

Sales.Desktop.Manager is an independent WPF client that calls the API (default base URL `https://localhost:7282/api/` configured in `Sales.Desktop.Manager\App.config`).

Sales.Ai is invoked by application services (via Sales.Services) to provide AI-driven features such as recommendations or text processing. It is intentionally kept as an integration layer so the implementation can swap providers or models without changing core domain logic.

Sales.MessageBroker defines message contracts and contains producers/consumers used by Sales.Api, Sales.Fulfillment, and other background services to perform asynchronous work and decouple components.

Sales.Fulfillment subscribes to order/payment events (via the message broker or direct service calls) and handles fulfillment workflows, external provider calls, and inventory reconciliation. It can run as a hosted worker process or container.

Prerequisites:

.NET 10 SDK

Visual Studio 2026 or `dotnet` CLI

SQL Server or other EF Core provider if using a real database

Project Description:

Sales.Api is the ASP.NET Core Web API project for the Sales sample application. It exposes the HTTP endpoints used by the desktop client and other consumers, implements business-facing controllers (products, shopping cart, etc.), and wires up services, EF Core, and third-party integrations.

Dependencies:

Sales.Domain — the domain model containing entities and value objects.

Sales.Services — application services used by the API controllers.

Sales.Data — EF Core data access layer; used for persistence and migrations.

Third-party packages: Swashbuckle.AspNetCore (Swagger), Stripe.net (payments), Microsoft.EntityFrameworkCore.* packages.

Prerequisites:

.NET 10 SDK

SQL Server (or your chosen EF Core provider) if you plan to run with a real database.

Project Description:

Sales.Data contains the data access layer for the Sales application. It includes the Entity Framework Core DbContext, entity configurations, and migration artifacts used to store and load domain data from the database.

Dependencies:

Sales.Domain — domain entities used by the EF model.

Microsoft.EntityFrameworkCore and the provider package (for example Microsoft.EntityFrameworkCore.SqlServer) — configured in the project file.

A startup project that configures DbContext at design-time (typically `Sales.Api`).

Prerequisites:

.NET 10 SDK

A supported relational database (SQL Server is used by default in this solution).

dotnet-ef CLI tool for managing migrations (optional if migrations are applied from another project).

Project Description:

Sales.Domain contains the core domain model for the Sales application. It defines entities, value objects, domain events, and domain-level invariants and logic. This project is intentionally free of infrastructure concerns so it can be reused and tested in isolation.

Purpose:

Define the domain entities (for example `Product`, `Order`, `CartItem`) and their behavior.

Contain domain services, value objects, and domain events.

Keep business rules and invariants centralized and implementation-agnostic.

Dependencies:

None on other solution projects — Sales.Domain should be framework-agnostic and contain only POCOs and domain logic. Higher-level projects (for example `Sales.Api`, `Sales.Services`, `Sales.Data`) depend on this project.

Prerequisites:

.NET 10 SDK

Project responsibilities:

No I/O or framework-dependent code (persistence, web, UI, or external APIs belong to other projects).

Provide clean interfaces and POCOs consumed by Sales.Services, Sales.Api, and Sales.Data.

Include validation and business rule enforcement at the domain boundary.

Project Description:

Sales.Services` implements application-level business logic and orchestration for the Sales solution. It sits between the domain model (`Sales.Domain`) and the API/UI layers, translating domain concepts into use cases and providing reusable service APIs for controllers and other callers.

Purpose:

Implement application services and use-cases (for example: cart management, checkout orchestration, product querying).

Coordinate between Sales.Domain and infrastructure layers (repositories, payment gateways).

Expose well-defined interfaces that can be consumed by Sales.Api and other clients.

Dependencies:

Sales.Domain` — domain entities and business types.

Sales.Data (or abstractions) — repository implementations or interfaces for persistence.

External integrations (for example payment or messaging clients) should be injected via interfaces.

Prerequisites:

.NET 10 SDK

Reference to Sales.Domain and Sales.Data (or repository interfaces) in the solution.

Project Description:

Sales.Utility contains shared utilities and helper code used across the Sales solution. This project hosts small, reusable components that are infrastructure-agnostic and can be referenced by multiple projects (API, services, desktop client, tests).

Purpose:

Provide common helpers (extension methods, logging helpers, validation utilities).

Centralize cross-cutting concerns that are not specific to a single layer.

Keep duplicates out of higher-level projects by offering reusable implementations.

Dependencies:

Minimal or no dependencies — `Sales.Utility` should be lightweight and avoid depending on higher-level solution projects. It may reference commonly used framework packages as needed (for example `Microsoft.Extensions.*`).

Prerequisites:

.NET 10 SDK

Project Description:

Sales.AI provides AI-assisted services used by the Sales backend (embeddings, semantic search, text generation and other AI utilities). The service component intended to be consumed by the larger Sales solution.

Key features:

Encapsulated AI client integration (Azure OpenAI / OpenAI compatible).

Helpers for text embeddings, semantic search, and prompt orchestration.

Configuration-driven endpoints and model selection.

Minimal dependencies so it can be used from other services in the solution.

Prerequisites:

.NET 10 SDK

An OpenAI-compatible endpoint (Azure OpenAI or OpenAI) and credentials if you will call external models.

Project Description:

Sales.Archives is the archival and retention module for the Sales backend.

Key features:

Archive storage abstraction (IArchiveRepository) allowing multiple backends: database, file store, blob storage.

ArchiveDbContext: EF Core DbContext for archive tables and metadata.

Retention policy enforcement and purge worker to remove expired records.

Soft-delete tracking and optional hard-delete processes.

Export/import helpers for packaged archive bundles (JSON/zip) for offsite storage or restore.

Audit metadata with who/when/why for archived items.

Query and retrieval APIs for reading archived records.

Project Description:

Sales.Fulfillment is the service responsible for processing orders, orchestrating fulfillment workflows, maintaining fulfillment-related data in the database, and exposing real-time updates via SignalR hubs for connected clients (dashboards, management UIs, and other services).

Overview:

Purpose: Process and manage order fulfillment tasks (pick/pack/ship), update fulfillment state, track shipments and inventory reservations, and provide operators with real-time telemetry and control.

Surface area: RESTful HTTP APIs for management/automation, SignalR hubs for live telemetry and notifications, background workers for long-running orchestration, and a DbContext for persistence.

Project Description:

Sales.Maintenance.Services contains background and operational services for the Sales backend.

Key features:

Hosted background workers for maintenance tasks:

• DataArchiveWorker: moves old data to archive storage and creates export packages.
• RetentionPurgeWorker: enforces retention policies and purges expired records.
• IndexRebuildWorker: scheduled index rebuilds/optimization for search stores.
• CacheWarmupWorker: pre-populates caches after deployments or restarts.
• HealthCheckReporter: periodic health aggregation and reporting.

Scheduling abstraction to drive intervals either via CRON expressions or fixed intervals.

Resiliency patterns: graceful shutdown, retries, and structured logging.

Pluggable adapters for storage, archive providers, and notification sinks.

Integration hooks for telemetry and alerting.

Project Description:

Sales.MessageBroker is a lightweight ASP.NET Core service that provides real-time telemetry, management APIs, and administrative tooling for the Sales message broker.

At a high level the project:

Collects and stores periodic metrics about broker topics (ingested messages, pending queue size, dead letters, last activity timestamps).

Exposes a SignalR hub to push live metric updates to browser dashboards and other connected clients.

Exposes HTTP management endpoints to operate on broker topics (replay DLQ, purge, snapshot, etc.).

Runs background services that aggregate metrics, clean up old records, and reconcile state with external queue systems.

Service responsibilities:

Metrics ingestion: periodic jobs read broker state (or receive events) and persist snapshots used for historic and realtime views.

Live push: when new snapshots are available the service broadcasts updates via SignalR.

Management actions: replaying DLQs, triggering snapshots, and manual cleanup operations are exposed via secure HTTP endpoints.