NilavPatel/dotnet-onion-architecture

This system is a .NET 8 web application implementing a Clean Architecture with distinct Domain, Application, and Infrastructure layers. It provides user management capabilities, including creation, validation, and retrieval of active users, supported by a Unit of Work pattern and repository abstractions. The system handles email services and database interactions via Entity Framework Core, with a focus on audit trails and soft-delete functionality for user entities.

The project now includes a Commands.md file that provides shell commands for building, running, and testing the backend solution, as well as generating the layered architecture (Domain, Application, Infrastructure, WebApi) and test projects. The README has been expanded to explain the Onion/Clean Architecture layers, domain model patterns, and validation strategies, while the solution file (MyApp.sln) has been restructured to reflect the new folder hierarchy and project references.

(repo-wide) · high confidence

The application layer now supports creating, validating, and retrieving active users. This includes new request models (CreateUserReq, ValidateUserReq), response models (CreateUserRes, GetAllActiveUsersRes, ValidateUserRes), and a UserDTO for data transfer. The UserService implements IUserService with methods to create users, validate user credentials, and fetch all active users, utilizing the Unit of Work pattern and repository layer. Additionally, an IEmailService interface and related models (Email, MailAttachment) have been reorganized and updated.

src/MyApp.Application · high confidence

The User controller now exposes two new API endpoints: a POST /api/user/validateUser endpoint that accepts a request object to validate a user, and a GET /api/user/getAllActiveUsers endpoint that retrieves all active users. The controller's route template was updated to include the 'api/' prefix and action name, and request/response models were updated to use specific DTOs (CreateUserReq/Res, ValidateUserReq/Res, GetAllActiveUsersRes) instead of raw domain models.

src/MyApp.WebApi/Controllers · high confidence

The domain layer now includes specific exception classes to handle user-related errors. A new UserStatus enum defines Active and InActive states, while UserIsNotActiveException and UserNotFoundException are introduced to signal when a user is inactive or cannot be found, respectively.

src/MyApp.Domain/Exceptions · high confidence

The application's domain layer has been restructured to provide a unified set of core abstractions. A new base entity model and auditable entity interface have been introduced to standardize entity definitions. The repository pattern is now encapsulated through a generic IBaseRepositoryAsync interface and an IUnitOfWork interface, promoting consistent data access strategies. Additionally, specification patterns for querying have been moved from the application layer to the domain core, with the BaseSpecification class updated to reflect the new namespace and property casing.

src/MyApp.Domain/Core · high confidence

Added a new static class UserSpecifications in the domain layer that provides reusable query specifications for retrieving users by email and password, and for fetching all active, non-deleted users. This change moves business logic related to user retrieval into the domain layer, improving separation of concerns and enabling consistent querying patterns across the application.

src/MyApp.Domain/Specifications · medium confidence

The application now uses a Unit of Work pattern to manage repository instances and database transactions. The UnitOfWork class has been added to coordinate repository access and save changes. Repository methods such as Add, Update, and Delete have been refactored to be synchronous and no longer automatically save changes to the database, allowing multiple operations to be committed in a single transaction. Additionally, the return types for list and single-item queries have been updated to use IList and nullable reference types.

src/MyApp.Infrastructure/Repositories · high confidence

The WebApi project has been refactored to use the minimal hosting model with a new Program.cs entry point, replacing the previous startup configuration. The application now explicitly registers application and infrastructure services, configures controllers, and enables Swagger for development. Additionally, the appsettings.json file was updated to use Windows Authentication for the database connection and adjusted logging levels for Microsoft.AspNetCore.

src/MyApp.WebApi · medium confidence

The EmailService was moved to the src directory and refactored to accept an Email domain model instead of multiple primitive parameters (from, to, cc, bcc, subject, body, attachments). This simplifies the method signature and aligns with domain-driven design principles. Additionally, error handling was improved by replacing manual string building with structured logging via an injected ILoggerService, providing better observability for failed email sends.

src/MyApp.Infrastructure/Services · high confidence

The application's legacy startup configuration and core application services have been removed. Specifically, the \Startup\ class in \MyApp.WebApi\ and the \Program\ entry point were deleted, along with the \UserService\ implementation and its associated repository and service interfaces in \MyApp.Application\. This eliminates the previous dependency injection registrations for repositories, email, logging, and user services, indicating a significant architectural shift away from the previous service-oriented structure.

MyApp.Application, MyApp.WebApi · high confidence

The \ApplicationDbContext\ class has been renamed to \MyAppDbContext\ and moved to \src/MyApp.Infrastructure/Data\. The namespace was updated from \MyApp.Domain.Models\ to \MyApp.Domain.Entities\. Additionally, a new initial migration (\20230810042311\_InitialMigration\) was added, which creates the \Users\ table with columns for identity, personal details, status, and audit fields.

src/MyApp.Infrastructure/Data · high confidence

A new User entity has been added to the domain layer, implementing IAuditableEntity and ISoftDeleteEntity interfaces to support tracking of creation and modification metadata as well as soft-delete functionality. The previous AuditableEntity base class has been removed, indicating a shift in how audit trails and entity lifecycle states are managed within the domain model.

MyApp.Domain · medium confidence

Added new test files covering the UserService (create and validate user scenarios), the SpecificationEvaluator helper for domain specifications, user-specific domain specifications, and the BaseRepositoryAsync implementation. These tests verify user creation, validation, and repository operations using in-memory databases and mocks.

src/Tests · high confidence

All projects in the solution have been upgraded from .NET 5.0 to .NET 8.0, enabling modern C\# features like top-level statements and nullable reference types. The project structure has been reorganized under a 'src' directory, and dependencies have been updated to their latest compatible versions (e.g., Entity Framework Core 7.0.0, NLog 5.0.4, Swashbuckle 6.2.3). Additionally, new test projects have been added for the Application, Domain, and Infrastructure layers, each configured with xUnit, Moq, and other standard testing libraries.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 46 → 47 (+0.9)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 83 → 83 (+0.0)
• Architecture 85 → 85 (+0.0)
• Maturity 65 → 65 (+0.0)
• Readiness 37 → 38 (+1.4)
• Security 36 → 37 (+1.1)

• Bounded contexts not declared
• Medium CVE: Azure.Identity 1.6.0
• Medium CVE: Azure.Identity 1.6.0
• No exposed public API
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness
• redundant comment (src/MyApp.Infrastructure/Repositories/SpecificationEvaluator.cs)

• CRAP 210: EmailService.SendEmail (src/MyApp.Infrastructure/Services/EmailService.cs)
• CRAP 42: SpecificationEvaluator.GetQuery (src/MyApp.Infrastructure/Repositories/SpecificationEvaluator.cs)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Low coverage: src/MyApp.Application/Core/Models/MailAttachment.cs (src/MyApp.Application/Core/Models/MailAttachment.cs)
• Low coverage: src/MyApp.Domain/Core/Specifications/BaseSpecification.cs (src/MyApp.Domain/Core/Specifications/BaseSpecification.cs)
• Low coverage: src/MyApp.Infrastructure/Repositories/BaseRepositoryAsync.cs (src/MyApp.Infrastructure/Repositories/BaseRepositoryAsync.cs)
• Low coverage: src/MyApp.Infrastructure/Repositories/SpecificationEvaluator.cs (src/MyApp.Infrastructure/Repositories/SpecificationEvaluator.cs)
• Low coverage: src/MyApp.Infrastructure/ServiceExtensions.cs (src/MyApp.Infrastructure/ServiceExtensions.cs)
• Low coverage: src/MyApp.Infrastructure/Services/EmailService.cs (src/MyApp.Infrastructure/Services/EmailService.cs)
• Low coverage: src/MyApp.Infrastructure/Services/LoggerService.cs (src/MyApp.Infrastructure/Services/LoggerService.cs)
• No test project references MyApp.WebApi (src/MyApp.WebApi/MyApp.WebApi.csproj)
• redundant comment (src/MyApp.Infrastructure/Services/EmailService.cs)

• Unchanged — 3 HTTP endpoints

• Unchanged — 2 containers · 1 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

NilavPatel/dotnet-onion-architecture was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.