Architecture : Overview

The solution generated by Scaffolder.net follows the principles of Clean Architecture combined with the Vertical Slices (Features) approach. This combination ensures a strict separation of concerns while keeping the organization centered on business features.

Clean Architecture organizes the solution into concentric layers where dependencies always point inward: the Domain depends on no other layer, the Application depends on the Domain, the Infrastructure.Persistence depends on the Domain and the Application, and the Presentation depends on the Application. This dependency inversion ensures that the business core remains independent of technical concerns.

• Domain : Contains entities, domain errors, domain events, repository and domain service interfaces, as well as FluentValidation validators. The Domain does not depend on any infrastructure or external framework.
• Application : Contains commands, queries, handlers, application services, command and query repositories, as well as domain event handlers. The Application orchestrates use cases by relying on abstractions from the Domain.
• Infrastructure.Persistence : Contains the Entity Framework Core DbContext, entity configurations, command, query and domain repository implementations, as well as the design-time factory for migrations. This layer implements the contracts defined by the Domain and the Application.
• Presentation : Contains Blazor Server pages and components, Blazor WebAssembly, or Minimal API endpoints depending on the configuration. The Presentation consumes application services without direct knowledge of the infrastructure.

• Presentation → Application : The presentation layer depends on application services (command and query services) but does not know about the Domain or the Infrastructure.
• Application → Domain : The Application depends on entities, repository interfaces and domain services defined in the Domain.
• Infrastructure.Persistence → Domain + Application : The Infrastructure implements the repository and domain service interfaces defined in the inner layers.
• Domain → none : The Domain does not depend on any other layer of the solution, ensuring complete independence of the business model.

The Shared projects contain abstractions and cross-cutting implementations reused by all bounded contexts: the Result pattern, Error types, the Mediator, Pipeline Behaviors, entity, repository and service abstractions, as well as Dependency Injection extensions. These projects avoid infrastructure code duplication across bounded contexts.

Within each layer, code is organized by Vertical Slices: each entity has its own Features/{Entity.NameSingular} folder that groups all files related to that entity. This approach improves cohesion, facilitates navigation between files of the same feature, and allows adding or removing an entity without impacting others.

• Commands : Groups write operations (Create, Edit, Delete) with their commands, handlers, requests, responses, validators and proxies. An Events folder contains the associated domain event handlers, and a Services folder exposes the command service that acts as a facade to the Mediator.
• Queries : Groups read operations (GetList, GetDetails, GetEdit, GetDelete) with their queries, handlers, requests, responses and proxies. A Services folder exposes the query service that acts as a facade to the Mediator.

The solution supports multiple bounded contexts, each representing a coherent domain boundary. Each bounded context generates its own Domain, Application and Infrastructure.Persistence projects, and can independently configure its presentation types (Blazor Server, Blazor WebAssembly, Minimal API). This modularity allows each context to evolve autonomously.

• Dependency inversion : Interfaces are defined in the inner layers (Domain, Application) and implemented in the outer layers (Infrastructure.Persistence), ensuring that the business does not depend on infrastructure.
• Encapsulation : Entities are sealed with private set properties and expose factory methods (CreateAsync, EditAsync, Delete) to guarantee the integrity of the business state.
• Explicit validation : Each command and entity operation is validated by FluentValidation before execution, with structured error return via the Result pattern.
• Feature cohesion : All files related to an entity (entity, errors, events, repositories, services, validators, commands, queries, handlers) are grouped in the same folder, improving maintainability.
• Read/Write separation : The CQRS pattern separates commands (write) from queries (read) with distinct repositories, allowing each side to be optimized independently.
• Automatic registration by reflection : Service, handler and repository registration in the DI container is done by reflection via marker interfaces, avoiding manual registration omissions.
• Global Usings : Each project generates a GlobalUsings.cs file with all necessary global using directives, eliminating using statement duplication.