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.

Projects:

Sales.Api — ASP.NET Core Web API and app host. Exposes HTTP endpoints and configures services, EF Core, and third-party integrations (Stripe, Swagger).

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

Sales.Domain — Pure domain model (entities, value objects, domain rules).

Sales.Services — Application services and orchestration (use-cases).

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

Sales.Desktop.Manager — WPF desktop client that consumes the API.

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`).

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