How anthueeccel/webstore works
1. Repository shape
- This is a multi-project .NET solution centered on WebStore.API, with supporting WebStore.Domain, WebStore.Infrastructure, and WebStore.Tests.
- The architecture is intentionally split into a thin API layer, a domain model layer, a persistence/infrastructure layer, and a separate test suite.
2. API style and runtime
- The API is an ASP.NET Core Minimal API running on .NET 10.
- Program.cs is the composition root: it wires dependency injection, registers endpoints, and boots the app.
- There are no MVC controllers; routing is organized through feature-specific endpoint classes.
3. Vertical-slice feature structure
- The API is organized by business capability, not by technical layer.
- Main feature groups are WebStore, Product, Brand, and Category.
- Each operation has its own folder containing the endpoint, handler, request/response models, and validator where needed.
- This means a single slice usually spans the full request path: HTTP endpoint → validation → handler → data access → response.
4. Command/query boundaries
- The codebase follows CQRS-style separation in practice.
- Write operations exist for Create, Update, and Delete flows, especially for WebStore and Product.
- Read operations exist for GetById, GetAll, and filtered queries such as GetProductsByWebStore.
- This keeps reads and mutations isolated at the handler level.
5. Domain model
- WebStore.Domain contains the core entities: WebStore, Product, Brand, Category, Address, plus BaseEntity.
- These are the business objects that map to the database and define the shape of the application’s data.
- The presence of BaseEntity suggests shared identity/auditing behavior across entities.
6. Data contracts and validation
- WebStore.API/Shared/Dtos holds DTOs used to move data between the API and clients without exposing domain entities directly.
- Shared/Validators contains reusable validation logic, including an AddressValidator.
- Feature-specific validators live beside their feature handlers, so input rules are localized to the slice that owns them.
- This boundary matters: endpoints speak in request/response models, while handlers work with domain and persistence concerns.
7. Persistence and infrastructure
- WebStore.Infrastructure contains the database implementation: WebStoreDbContext, EF Core migrations, and seeders.
- The infrastructure project is the bridge from application logic to the database.
- IWebStoreSeeder and WebStoreSeeder indicate initial data population is part of the infrastructure story.
- ServiceCollectionExtensions in both API and Infrastructure suggests DI wiring is split by responsibility.
8. Database lifecycle
- EF Core migrations are checked in, so schema evolution is managed in code.
- The repo includes an initial migration and a model snapshot, which means the database schema is versioned alongside the application.
- The README references PostgreSQL/Neon for deployment, while the test tooling references SQL Server containers; architecturally, the repository is built around EF Core with environment-specific database configuration.
9. Testing strategy
- Unit tests are organized by feature and target the handlers directly, which validates business logic without going through HTTP.
- Integration tests live separately and exercise the API/database boundary, including endpoint tests and database connection checks.
- The test layout mirrors the production feature layout, which makes it easy to trace a failing test back to a specific slice.
10. CI/CD and deployment
- .github/workflows/dotnet.yml defines a GitHub Actions pipeline for build, test, artifact creation, and deployment.
- The pipeline runs on pull requests to main and includes multiple test stages, including integration/E2E-style checks.
- The deployment target is Azure App Service, so the production boundary is externalized from the application code.
- This repo treats CI/CD as part of the architecture, not just a build script.
11. External tooling and contract-first workflow
- The README describes a spec-driven workflow using Bruno collections as the API contract.
- That means endpoint shape is validated before and during implementation, making the HTTP contract an important architectural boundary.
- Bruno is therefore not just a test tool; it acts as a specification artifact for the API surface.
12. End-to-end request flow
- A typical request comes from a client or Bruno test into a feature endpoint.
- The endpoint binds request data, validates it, and passes control to the handler.
- The handler uses infrastructure services such as DbContext and returns a feature-specific response DTO.
- The response exits back through the Minimal API pipeline, with the domain model remaining internal to the service.
Main entry points: WebStoreDbContext.cs DbContext · Program.cs Program · Features Handler tests · WebStore WebStore
Components 15
API
Minimal API composition root, shared contracts, and feature slices
- Program · Bootstraps the Minimal API, DI, and endpoint wiring
WebStore.API/Program.cs - API DI · Registers application services and shared API dependencies
WebStore.API/Shared/Extensions/ServiceCollectionExtensions.cs - DTOs · Shared request/response data contracts for the API surface
WebStore.API/Shared/Dtos - Validators · Reusable validation rules shared across feature slices
WebStore.API/Shared/Validators - WebStore · Create, read, update, and delete operations for stores
WebStore.API/Features/WebStore - Product · Product commands and queries, including store-scoped reads
WebStore.API/Features/Product - Brand · Brand read endpoints
WebStore.API/Features/Brand - Category · Category read endpoints
WebStore.API/Features/Category
Domain
Core business entities
- Entities · WebStore, Product, Brand, Category, Address, and shared base entity
WebStore.Domain/Entities
Infrastructure
EF Core persistence, migrations, and seeding
- DbContext · Database session and model configuration
WebStore.Infrastructure/Persistence/WebStoreDbContext.cs - Migrations · Versioned EF Core schema evolution
WebStore.Infrastructure/Migrations - Seeder · Initial data population for the database
WebStore.Infrastructure/Seeders/WebStoreSeeder.cs
Tests
Handler-level and integration test suites
- Handler tests · Feature-level tests that exercise handlers directly
WebStore.Tests/Features - Integration tests · Endpoint and database boundary checks
WebStore.Tests/IntegrationTests
Delivery
CI/CD and deployment pipeline
- CI pipeline · Build, test, artifact, and deployment workflow
.github/workflows/dotnet.yml
Connections 29
- Program → API DI: loads services · Composition root wires application and infrastructure services
- Program → WebStore: maps endpoints · Minimal API registration for the WebStore slice
- Program → Product: maps endpoints · Minimal API registration for the Product slice
- Program → Brand: maps endpoints · Minimal API registration for the Brand slice
- Program → Category: maps endpoints · Minimal API registration for the Category slice
- WebStore → DTOs: returns DTOs · Feature responses use shared API contracts
- Product → DTOs: returns DTOs · Feature responses use shared API contracts
- Brand → DTOs: returns DTOs · Feature responses use shared API contracts
- Category → DTOs: returns DTOs · Feature responses use shared API contracts
- WebStore → Validators: validates input · Feature requests are validated before handler execution
- Product → Validators: validates input · Feature requests are validated before handler execution
- Brand → Validators: validates input · Feature requests are validated before handler execution
- Category → Validators: validates input · Feature requests are validated before handler execution
- WebStore → DbContext: queries writes · Handlers access persistence through EF Core
- Product → DbContext: queries writes · Handlers access persistence through EF Core
- Brand → DbContext: queries · Read handlers query the database through EF Core
- Category → DbContext: queries · Read handlers query the database through EF Core
- DbContext → Entities: maps entities · EF Core model is built from the domain entities
- DbContext → Migrations: evolves schema · Schema changes are tracked in checked-in migrations
- Seeder → DbContext: seeds data · Seeder populates the database through the context
- Handler tests → WebStore: covers · Handler tests mirror the WebStore feature slice
- Handler tests → Product: covers · Handler tests mirror the Product feature slice
- Handler tests → Brand: covers · Handler tests mirror the Brand feature slice
- Handler tests → Category: covers · Handler tests mirror the Category feature slice
- Integration tests → Program: boots through · Integration tests exercise the API entry point
- Integration tests → DbContext: verifies db · Integration tests check database connectivity and behavior
- CI pipeline → Handler tests: runs · CI executes unit tests as part of validation
- CI pipeline → Integration tests: runs · CI executes integration checks as part of validation
- CI pipeline → Program: builds · Pipeline builds the API project for deployment