-
Notifications
You must be signed in to change notification settings - Fork 14
Open
Labels
.NETPull requests that update .NET codePull requests that update .NET codeenhancementNew feature or requestNew feature or request
Description
Description
The current folder structure follows a traditional layered architecture (Controllers β Services β Repositories β Data) which, while functional, has some architectural limitations:
src/Dotnet.Samples.AspNetCore.WebApi/
βββ Controllers/ # HTTP/API concerns
βββ Services/ # Business logic + orchestration
βββ Repositories/ # Data access abstractions & implementations
βββ Data/ # EF Core DbContext
βββ Models/ # Mix of entities + DTOs
βββ Enums/ # Domain enums
βββ Validators/ # Input validation
βββ Mappings/ # Object mapping
βββ Utilities/ # Various utilities
βββ Configurations/ # Infrastructure configuration
βββ Extensions/ # Service registration
- Business logic is mixed across multiple layers
- Dependencies flow in all directions, making testing difficult
- Tight coupling between infrastructure and business logic
- Limited ability to swap implementations (database, external services)
This issue proposes migrating to Clean Architecture-inspired folder structure to improve maintainability, testability, and adherence to SOLID principles.
Proposed Solution
Restructure the project into Clean Architecture layers with proper dependency inversion:
src/
βββ Dotnet.Samples.AspNetCore.WebApi.Domain/
β βββ Entities/
β β βββ Player.cs # Pure domain entity
β βββ Enums/
β βββ Enumeration.cs
β βββ Position.cs
β
βββ Dotnet.Samples.AspNetCore.WebApi.Core/
β βββ DTOs/
β β βββ PlayerRequestModel.cs # Input DTOs
β β βββ PlayerResponseModel.cs # Output DTOs
β βββ Interfaces/
β β βββ IPlayerRepository.cs # Repository contracts
β β βββ IPlayerService.cs # Service contracts
β β βββ IRepository.cs # Generic contracts
β βββ Services/
β β βββ PlayerService.cs # Business logic orchestration
β βββ Validators/
β β βββ PlayerRequestModelValidator.cs
β βββ Mappings/
β β βββ PlayerMappingProfile.cs
β βββ Exceptions/ # Custom business exceptions
β
βββ Dotnet.Samples.AspNetCore.WebApi.Infrastructure/
β βββ Data/
β β βββ PlayerDbContext.cs
β βββ Repositories/
β β βββ Repository.cs # Generic implementation
β β βββ PlayerRepository.cs # Specific implementation
β βββ Migrations/ # EF Core migrations
β βββ Extensions/ # Infrastructure-specific extensions
β
βββ Dotnet.Samples.AspNetCore.WebApi.Api/
βββ Controllers/
β βββ PlayerController.cs
βββ Configurations/
βββ Extensions/
β βββ ServiceCollectionExtensions.cs # DI configuration
βββ Utilities/ # Presentation utilities
βββ Program.cs # Application entry point
Dependency Flow
Api β Core β Domain
Infrastructure β Core β Domain
Suggested Approach
-
Create Domain project (
Domain/)- Move
Models/Player.csβDomain/Entities/Player.cs - Move
Enums/βDomain/Enums/ - No external dependencies
- Move
-
Create Core project (
Core/)- Move
Services/βCore/Services/ - Move
Models/PlayerRequestModel.cs, PlayerResponseModel.csβCore/DTOs/ - Move
Repositories/IPlayerRepository.cs, IRepository.csβCore/Interfaces/ - Move
Validators/βCore/Validators/ - Move
Mappings/βCore/Mappings/ - Reference: Domain only
- Move
-
Create Infrastructure project (
Infrastructure/)- Move
Repositories/Repository.cs, PlayerRepository.csβInfrastructure/Repositories/ - Move
Data/βInfrastructure/Data/ - Move
Migrations/βInfrastructure/Migrations/ - Reference: Domain, Core, EF Core packages
- Move
-
Refactor API project (
Api/)- Rename current project from
WebApitoApi - Keep
Controllers/,Program.cs - Update
Extensions/ServiceCollectionExtensions.csfor DI configuration - Reference: Core only (not Infrastructure directly)
- Rename current project from
-
Update Solution and Tests
- Update
.slnfile with new project references - Update test projects to reference appropriate layers
- Ensure all tests pass after migration
- Update
Acceptance Criteria
- Domain project contains only pure domain logic with no external dependencies
- Core project contains business logic and defines infrastructure contracts
- Infrastructure project implements Core interfaces and handles data access
- Api project contains only HTTP/presentation concerns
- Dependency flow follows Clean Architecture principles (inward dependencies only)
- All existing tests pass after migration
- No circular dependencies between projects
- Build and deployment work without issues
- Docker compose still functions correctly
- Database migrations continue to work
- API functionality remains unchanged (same endpoints, same behavior)
References
Metadata
Metadata
Assignees
Labels
.NETPull requests that update .NET codePull requests that update .NET codeenhancementNew feature or requestNew feature or request